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Preface 


Some justifications may be needed for a new book on Algol 60. Since 1960, 
the many books which have appeared — the ‘primers’, the ‘introductions’ 
and ‘guides’ — have generally taken an empirical approach towards the 
use of Algol, relying heavily on ‘mules of thumb’ and often leaving unsung 
the structual features of the language. This approach is perhaps the only 
one for the predecessors of Algol, for Fortran, the Autocodes, and lower 
level ‘languages’, since they are often a disconnected collection of 
facilities, with no basic architectural aims. But Algol was conceived as 
a structural entity, as a language with a formal syntax, or grammar, and 
was the first general purpose computer language to be so. Consequently, 
one may take advantage of this effect, as with any grammatically deter- 
mined language, and express its correct use through a formal descriptive 
method — a syntax embodying the grammar. In this way one is led to the 
generation of correct ‘sentences’ or ‘productions’ of the substitutional 
syntax. 

Curiously enough, although few people educated enough to make use of 
computers will have escaped high school immersion in the formal 
grammatical studies of their native language, the view seems to persist 
that study of a computer language by this means is somehow to be 
avoided, at risk of putting such people off. In any event, the author’s view, 
conditioned by several years experience in trying to teach Algol at 
university level, is that people will delight in the specially simple and 
consistent grammar which describes Algol 60. Once understood, the 
syntax specifications give a simple method of determining a correct 
program, by checking the substitutions of the various ‘metavariables’, or 
conceptual devices used to define the language. Thus, in order to see 
whether he has written a correct statement, the reader can check through 
the elaborations of it, conveniently through the Syntax Summary given in 
Appendix 3 of this book; ultimately he will have the basic symbols which 
are the productions of the syntax, and can see if his interpretation is 


correct. The spirit and powerful structural definition of the language so 
give one a ‘feeling’ for what is in the spirit, for what is valid. 

The approach throughout this book, therefore, is to use the formal 
method of syntactic description, slightly modified, used in the Revised 
Report, ' and called the Backus—Normal Form notation. 

Another reason for the book lies in the increasing scale of adoption 
by manufacturers and systems designers, of the ACM Input—output pro- 
posal. By far the most powerful system to be given for Algol 60 input— 
output, the ACM scheme has been adopted, along with the IFIP (Inter- 
national Federation for Information Processing) input—output procedures, 
into a Draft International Standard for Algol 60, by the International 
Standards Organisation (ISO). This book describes this system for the 
first time, outside the official reports. 

Again, many previous texts stop short at the so-called, ‘advanced’ 
features of Algol 60, e.g., procedures and their applications. A special 
effort has been made to allow the reader to realize their full potential. In 
particular, he should feel encouraged to make use of the vast and growing 
literature in which algorithms for both numerical and non-numerical 
computations are described by means of Algol 60 procedures. Some of the 
best quality algorithms start off as Algol 60 procedures, functioning 
primarily as models for the processes concerned. Since the language has 
a definitive standard, it serves as the main publication vehicle for 
algorithms, though many find their ways into other languages subsequently. 
Because of its status as a defined medium, no ambiguity in terms of 
machine limitations and local language definitions is possible, unlike 
many other programming media. 

Grateful thanks are due to David Brown, of Chelsea College, and David 
Hill, Chairman of the British Computer Society Algol Specialist Group, 


for reading and criticizing the manuscript, and making many helpful 
suggestions. 


R. F. Shepherd 


1 


Fundamental Concepts 


1.1. Introduction 


Algol 60 is one of an increasing class of programming media called a 
‘high level language’. This means it is designed to facilitate the 
expression of problems in a way which represents a compromise between 
the normal mode of description by the programmer, for example ordinary 
mathematical formulae, and the language of the computer, which operates 
in terms of very simple machine instructions. The ‘machine code’ is tire- 
some and difficult to use by the casual programmer, and its proper use 
means becoming very familiar indeed with a particular computer. Most 
computer users cannot afford the time to become so proficient, and are 
prepared to settle for the compromise. It is a compromise, because in- 
herent inefficiency faces the user of a high level computer language. 
This inefficiency arises from the process by which such a high level 
program text, expressed as a punched card deck, or roll of paper tape, 
prepared on suitable punch machines, is translated into the machine 
instructions. A special program, called a compiler, is needed, which will 
accept the high level program text as if it were data and analyse it, pro- 
ducing various intermediate reduced states of the original text, each 
state being closer to the final aim of an executable machine code trans- 
lation of the original program. Often such an original program is called 
the ‘source program’, and its translated version the ‘target program’. It is 
impossible to eliminate entirely the generation of some superfluous 
machine instructions in such a complex process, and since these instruc- 
tions must subsequently be executed in the execution phase of the trans- 
lated program, a source of inefficiency is inevitable. It is worth just 
recapitulating the process: the source text, prepared on a keypunch (for 
punched cards), or teleprinter (for paper tape), is entered into the com- 
puter under the control of the compiler program. The source text is then 
input and stored, although a certain amount of preliminary sorting and 
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te-atrangement usually takes place at this stage. The compiler will then 
repeatedly scan the stored source text, analysing and processing it, 
allocating storage for the program variables, and setting up the various 
internal linkages. By this time, the original program will be in some form 
of internal semi-code translation stage. In some compilers, this semi-code 
will be executed by the compiler taking each pseudo-instruction and 
interpreting it in terms of the basic machine code before executing it. 
This mode of approach, which is generally slower, is called an inter- 
pretive compiler; some advantage is accrued from the fact that since each 
semi-code has not been reduced to several machine instructions, it takes 
up less space in the machine; such a compiler may often be found in 
conjunction with small computers. More often, the semi-code will be 
again scanned, and a final translation into machine instructions is 
effected. This ends the ‘compilation phase’, and the target program can 
now exist and be executed in its own right. Quite often the compiler, or 
part of it, can now be dispensed with. Many compilers will allow a pro- 
gram, which needs to read in data on which it can operate, to over-write 
the compiler. Nevertheless, of course, a copy of the compiler will be 

kept on some backing-store device, such as a magnetic disc or tape, so 
that other jobs can be subsequently translated and run. 

Needless to say, the writing of a compiler program is one of the most 
exacting programming tasks, and is a highly technical problem. Some idea 
of the problem can be gained from the specialist books.*'? 

The inefficiency inherent in this mode of programming is offset to a 
large extent by the reduction in programming time necessary to solve a 
problem. Certainly, few casual computors will want to become machine- 
code experts, and it is to them that such a book as this is addressed, in 
the hope that Algol 60 will become the natural extension of their normal 
mode of expressing problems in mathematical notation. 

Indeed, Algol 60 is now the most widely current of general purpose 
computer languages for algorithmic expression. Many texts, journals and 
papers use it to define numerical methods, even though in practice these 
algorithms sometimes find their final expression in other computer 
languages. The reason for this wide currency is of course the rigid defi- 
nition which the language has by virtue of the Revised Algol Report.’ 

No other language has gained such a rigid and definite standard of speci- 
fication at international level. Because of this definite specification, 
there is an almost complete lack of ambiguity in its use. 

The use of Algol 60 as a medium to define numerical processes 
programmatically has led to some major efforts to establish collections 
of highly tested algorithms in the form of a library. “In this way a collec- 
tion of numerical models can be made which either serve to define a 
method, for direct use in an Algol 60 program, or as a model for 
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translation into other programming languages. This kind of library concept 
is central to the efficiency of computer use, because it avoids the costly 
duplication of programming effort, where one person codes an algorithm, 
in ignorance that someone else has already done so. 

One of the features of Algol 60, which differentiates it from, say, 
Fortran, is that its definition is given in a special way. In fact a 
language (often called the metalanguage  ) for describing the language 
has been invented; developed by J.W. Backus, the notation is used in the 
Revised Algol Report. | The reader is recommended to study its formalism, 
for its application in defining the language is used throughout this book. 
Its man purpose is to avoid the inevitable ambiguity of phrase which 
follows the use of plain English. In fact, in order to define some con- 
cepts in the language, a considerable amount of plain English description 
would be needed. The metalanguage avoids this, by expressing the 
language syntax in a precise manner, rather like mathematical formulae. 
Thus a programmer may always check his program — for syntactic correct- 
ness (it might still be nonsensical !) — by consulting the formal syntactic 
definitions of the language elements he has used. For example, in 
Fortran, a forerunner of Algol 60, plain English description is used, and 
a programmer may spend a considerable time trying to decide whether his 
efforts are correct or not. Often the lack of any generally agreed definition 
of Fortran means that one does not know in advance whether a certain 
feature of the language is available. Thus one consults the manual, and 
standards of documentation are often such that the only answer is to 
‘try it and see’. The Algol 60 metalanguage is a conceptual device, and 
no one is bound to its use absolutely, as long as the language so defined 
remains the same. In parts of this book we shall occasionally depart from 
the Algol Report in so far as the metalanguage definition is concerned. 
For example, it is often a point in favour of clarity to further elaborate 
the syntax, so that particular features may be analysed. Some interesting 
new m2talanguages have been created in recent years,” mainly as 
vehicles for the description of new languages. 


1.2 History and status of Algol 60 


The basis of most current implementations of Algol 60 is the Revised 
Report. | Some earlier versions of the language ” had certain ambiguities 
which have to a large extent, though not entirely,” been eliminated. It is 
often only when people actually have to write compilers for a new 
language that such ambiguities are discovered, and the period 1960-62 
was rife with such examples. The lesson clearly pointed to in this exper- 
ience is that, before a language reaches the statute book of any standards 
authority, it ought to have stood the test of at least one complete 


ALGOL 60 PROGRAMMING 


implementation, and a period of use. Often there turn out to be conflicting 
features, and such experience — very difficult wholly to foresee — might 
substantially affect the eventual decision as to whether one or other of 
these features should be redefined, or even dropped. 

Several intemationa! organizations are involved in the question of 
programming language standards, and in definition. It is certainly not 
possible to look to any one of them as completely authoritative in this 
field, although the International Federation for Information Processing 
(IFIP), which was created in 1960, around the same time as Algol, has 
rapidly gained a position of pre-eminence. Run by a Council of experts 
of international repute, it consists of many specialist committees involv- 
ed in research, definition and standardization, on a wide variety of 
information processing topics. These committees, of which Technical 
Committee 2 (TC 2) is responsible for programming languages, are too 
big to handle the detailed work of language definition, and in practice 
this is performed by special working groups, consisting again of inter- 
national experts from many countries. Algol] is the province of working 
group 2.1 (WG 2.1), which since its inception has been chaired by 
W.L.v.d. Poel (Netherlands) and more recently by M. Paul (Germany). 
Some interesting early history of Algol, by one of its prime movers, is 
contained in Description of Algol 60,° which is concerned with the 
Subset definition, ® which we consider briefly in chapter 10. Like most 
international groups, the path of progress for IFIP has not always been 
smooth, certainly where Algol was concerned. The conflicting interest 
and diversity of the combatants has often made agreement difficult, 
and one casualty has been the development of Algol 60. The language 
described in this book is in fact mainly the approved IFIP version; 
however the section of it dealing with input-output, while partially 
including the IFIP standard (chapter 8), is pitifully inadequate. For 
this reason, the input-output proposal drafted in 1963 by the American 
Association for Computing Machinery "' has been adopted by several 
implementors, and in fact this proposal is at the time of writing part of 
the standard Algo] 60 Draft of the International Organization for 
Standards. 

Input and output syntax was not sufficiently advanced in definition 
for inclusion in the Revised Report; ; consequently the Report emerged in 
1962, with rules permitting the writing of Algol programs, but no rules for 
inputting and outputting data and results. This curious anomaly meant 
that any actual implementation had to use mules for input—output devised 
solely by the implementors; consequently many compilers in use today 
have totally different conventions for input—output, and the reader should 
consult the Algol manual for his particular installation in order to see 
what has been decided upon. 
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It is a fundamental truth that the user only gets what he asks for, and 
chapter 9, which descibes the ACM/ISO proposal for input-output for the 
first time in book form, is given in the hope that many users will press 
their computer centres to adopt it. Comparatively little extra work is 
involved in the writing of a set of procedures, and this will certainly be 
practicable for the larger machines. The user will thus acquire access 
to a very comprehensive and flexible input—output system. The signs of 
recent years are that most new compilers are adopting the ACM/ISO con- 
vention; it remains to be seen whether any of the existing systems 
offered with certain computers will be modified, and such matters are 
very largely in the hands of the users. 

In summary, the Algol 60 documents which carry the approval of the 
IFIP Council are 


(a) The Revised Report : 
(b) The Report on Subset Algol'° 


(c) The Report on input—output procedures ea 


The ACM input—output proposal” has been revised by Subcommittee 5, 
Programming Languages, of Technical Committee 97 of the International 
Standards Organization; it now includes (c) above. Thus (a), (b), (c) and 
the ACM proposal have been forged by TC 97 into one comprehensive 
Draft Algol Proposal, which forms the basis of this book. 


1.3. The metalanguage 


The constituents of a mathematical expression are things called vari- 
ables and constants, and the various operators linking them. The object 
of Algol 60 is to provide a convention for reproducing such expressions 
in a totally unambiguous manner. We often forget just how imprecise 
ordinary mathematical notation is; for example, which interpretation is to 
be given to the expression 


a/bxec 


Is it to be ac/b or a/be, i.e., 5 x ¢ or ee? The use of parentheses will 


help — but of course we are then already specifying a syntactic structure. 
Thus the metalanguage is a notation for expressing a language — just as 
mathematical notation expresses the formal structure of formulae. 

Just as, in mathematics, one defines differential operators, matrices, 
vectors and so forth, either by their explicit properties and appearance, 
or their transformation properties, so, in Algo! 60, shall we define 
variables, numbers, statements and expressions. The definitions of these 
entities will be given in a precise context, and to avoid confusing them, 


ALGOL 60 PROGRAMMING 


in the text, with their more conventional meanings, the notation 
encloses them in brackets thus: (statement). When one speaks of a 

« Statement) it will then be clear that this is in the Algol context, and 
not merely an ordinary statement. The interface between a mathematical 
problem, and its expression in Algol is often so blurred that this con- 
vention is positively helpful. For example, a <variable> in an 

< expression) may not take the same form as a variable in an expression 
(depending on what that is !). 

The entities in Algol 60 are closely allied to their conventional 
equivalents, so that a <variable) will represent a variable in a mathe- 
matical expression. These entities can be described as the metavariables 
(of the metalanguage); their definition will be in the form of formal rules 
of syntax, which give their expression in terms of other metavariables. 
By a process of substitution of one meta-equation in terms of another, 
we arrive finally at a ‘terminal rule’ (or ‘production’) which is a (basic 
symbol» , i.e., a character which may actually appear in the source 
Program text. 

The metavariable which we require to define syntactically (the 
definiend) is enclosed in the angular brackets (and). The symbol 
‘::=’ denotes the meta-equation (the quotes are not part of it — illustrat- 
ing one of the difficulties of formal syntax, and the need for it). One 
reads ‘::=’ as ‘is defined as’. If there are two or more classes on the 
right of the meta-equation, i.e., the definiends, these are separated by 
the vertical bar symbol ‘|’, which must be read as ‘or’. 

A not very apt example is the entity of (person) ; one could write the 
meta -equation 


(person) ::= male) | (female) 


Thus defining two classes. Further rules could be 


{male ::= (boy) | Cyouthy | Cold many | man) 


The reader will no doubt elaborate his own ideas for (female) . Without 
taking this example too seriously, one could envisage a plural form, 
expressed recursively as 


(males) i= (male) male) | males) <male> 


The sense of this is that the class (males) must contain at least two of 
the class (male) ; the part of the definition following the ‘|’ then 
expresses recursively that the whole class of (males) must consist of 
at least two, followed by a third, and so on. Actually this kind of recur- 
siveness is something of an artificiality, and can be formally eliminated 
by an alternative notation such as 
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<males) ::= male} 


which indicates a class of at least two, but otherwise indefinite string of 
categories of (male) . This more economic form has been used recently® 
in an attempt to remove this kind of formally redundant recursive defi- 
nition. 

There are many metavariables which cannot be defined other than 
recursively however; usually because they link two or more interdepend- 
ent definitions. A good example is any attempt to define the components 
of an arithmetic expression, for here one finds the terms of such an 
expression may be themselves sub-arithmetic expressions. Essentially 
there is no escape from this dilemma; the expression must be defined in 
terms of its constituent parts, variables, operators and constants and 
functions, which are themselves of necessity defined in terms of the 
arithmetic expression. We shall encounter this situation frequently. 

As another example, we cite a rather simple ‘language’ with its sen- 
tences made up of only two symbols ‘a’ and ‘b’, occurring in various 
juxtapositions as the ‘grammar’ characterizes. First we define the 
‘terminal productions’, i.e., the metavariables which transform only into 
the symbols ‘a’ or ‘b’. 


fa) ::= a (a) <b> ::= b= (b) 


That is, ‘a’ and ‘b’ are sentences in the simple language. The actual 
grammar can be described by the meta-equations 


Keo) ::= da | <b> (c) dy ::= ©|@, © @Wd 
These two equations constitute the syntactic specifications for the 
simple language, and any occurrence of ‘a’ or ‘b’ or combination of them 
not given as valid by (c) or (d) will be ungrammatical. 

Now examine the following sentences 


(i) a (iv) a, a, a (vii) a, 
(ii) b (v) b, b, b, b, a (viii) , a, b 
(iii) a, b (vi) a, b, a, b (ix) ab 


Clearly (i) is correct, by (c) and (a), and similarly for (ii). Also (iii) is 
correct, for it follows from (d), (c), (a), (b) in that order. Similarly (iv), 
(v), (vi) are correct productions of the syntax given in (a—d). But (vii), 
(viii), (ix) are not. The comma in (vii) can only occur, according to (d), 
if another class (‘a’ or ‘b’) follows it, which it does not. Similarly with 
(vii) and (ix). 

The process of applying the transformation mles (a—d) can be looked 
upon as successive stages towards the removal of the brackets and) to 
produce actual symbols, or terminal productions which are regarded as 
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Sentences in the formal language. Observe that ‘a,b’ is a correct sen- 
tence, because both ‘a’ and ‘b’ are correct productions of (a) and (b). 
Their joint occurrence is a correct deduction from (c), and their delimeter 
‘,’ is a correct deduction from (d). A reduction like this to determine 
whether a given sentence in such a language is correct is called a ‘parse’. 
Many compilers work in this way, the analytical part of the compilation 
phase being virtually a parsing of the source program syntax. In such a 
way, of course, even (program) has to have a definition, and we shall find 
such a program) in Algol 60. 


1.4. Basic symbols 


As we have observed, a formal language like Algol 60 has certain terminal 
productions, which are the (basic symbol)s of its sentences. Indeed some 
sentences will consist of just one (basic symbol), as in the example dis- 
cussed in 1.3. The symbols used in Algol 60 are given in full in appendix 
1, in conjunction with some of the commoner actual representations used 
on computers. A real difficulty with Algol 60 is that some 116 (basic 
symbol)s are defined, and few machines for punching cards or paper tape 
have as many graphics as are needed. Some economies can be made by re- 
using certain symbols. Thus ‘:’ is a (basic symbol) , which can be used 
to make ‘:=’, the ‘=’ part of which can also be re-used from the (basic 
symbol) ‘=’, and so forth. 

Some of the (basic symbol) s are complete words, for example, begin, 
go to. These have a specific syntactic function in a <program) , more or 
less in keeping with their conventional meanings. They cannot be separ- 
ated however; for example, go to is a complete (basic symbol). There is 
no “basic symbol) such as go or to, and no (program) would be correct 
in using them. The (basic symbol>s can only appear in the form given in 
the appendix 1, combined according to the syntactic rules which this book 
describes. It needs to be emphasized though, that the syntactic rules can 
only allow one to produce a syntactically correct program . For example, 
the English sentence: ‘the cat is nine tenths dog’ is syntactically 
correct, but semantically meaningless. Thus any formal language has to 
be ‘given both a syntactic specification and a semantic one. Some recent 
developments ” in formal language definition are tending towards a com- 
plete specification in terms of formal syntax, though the evidence of such 
attempts is that they are extremely hard to understand. 


1.5 Scope of Algol 60 


Quite the greatest part of non-commercial data processing takes place in 
the field of computation. This includes the many scientific and engineer- 
ing disciplines, which find their computational expression in formal 
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calculations, from mathematical formulae, equations and so on. Algol 60 
was designed with this specific purpose in mind, and it is often regarded 
as unsuitable for such applications as information retrieval, simulation 
and symbol manipulation, though it has been used effectively in such 
fields.'*? However, such applications are only a small proportion of the 
use of computers, and the tendency is for special purpose languages to 
be developed for them. We shall not make any real attempt in this book 
to show such applications, but develop the language with calculations 
specifically in mind. 

Thus the next few chapters are concerned with developing a syntax for 
the representation of arithmetic expressions, their computation and as- 
signment to variables, by means of statements. One of the first things is 
to define values, distinguishing floating decimal numbers and integer 
numbers, since these are represented differently in most computers. 

But first, it is some help to examine a general arithmetic expression, 
and try to envisage the scope of necessary definitions. 


1.6 Comments 


Provision is made, subject to certain conventions, for the insertion in a 
< program ) of explanatory material, or commentary, which might be useful 
in understanding certain steps. We shall from time to time make use of 
this, and it is understood that, within the commentary, with the exception 
of certain (basic symbol)s, any kind of symbol, in any order may 
appear. There are three kinds of comment facility: 


commentary convention equivalent 
(i) comment Cany character sequence not ; 
containing ; > ; 
(ii) begin comment (any character dequence begin 
not containing ; > , 


(iii) end (any sequence of characters not 
including the (basic symbol)s end or end 
; or else) 


2 


Arithmetic Expressions 


2.1 Syntactic requirements 


In considering the scope of any syntactic definition for representation 
of, say, an arithmetic expression, consider, for example, that given by 


- 23(asec' pi bx xxc,,x In(x+ sin p)) 
283.86 » J,Gxp)+t 
This rather complicated expression illustrates the kind of representa- 
tional problem the language definition faces. It must distinguish 
subscribed variables, like C,,2, functions like J,’ 4 first-kind Bessel, of 


fairly rare occurrence, and sin, which occurs much more often. The 
components of (2.1) can be categorised as follows: 


(2.1) 


t,jrtk 


decimal integer 23 

: : (constants) 
decimal fraction 283.86 
simple (unsubscripted) 
variables a, b, x, p 
subscripted variables Cres bingy ek 
functions In, sin, sec", J, 


It is necessary to differentiate formally between these. A constant 
like ‘23’ refers to an integral quantity, held exactly, whereas 283.86 is a 
a decimal fraction, implying a limited (finite) accuracy which might be 
stored as a floating decimal number, (see 2.2). Observe also the 
necessity to distinguish the meanings of the decimal point in ‘283.86’ so 
that it could not mean ‘283 x 86’. Clearly a defined form for a number is 
needed. Subscripted variables involve computations of the numeric values 
of their subscript expressions (which could again be arithmetic ex- 
pressions) in order that the position of the element in the array named by 
the subscript variable (f and c in 2.1) can be found. The actual element 
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in the array can then be referenced. This process is clearly more 
complicated than for simple variables, which simply name locations in 
the computer memory, rather than reference them by numeric addresses. 
Thus a different kind of syntactic definition must be given, which we 
shall call (simple variable) and ¢ subscripted variable), and they will 
be also declared differently in the program. Constants will not require 
definition, but close contro! over their legal form will give rise to the 
metavariable (number). 

The functions will all be defined similarly, by means of a metavariable 
called a < procedure declaration) . This corresponds to the machine code 
concept of a subroutine, i.e., a utility code, with fixed conventions for 
parameter location. Only the common mathematical functions are defined 
as part of the system, as ‘standard functions’, whereas the less common 
functions, such as Bessel’s, have to be defined by the programmer, per- 
haps using a library provided. 

The elements of an arithmetic expression have numerical values, and 
we now turn to how this is defined. 


2.2. Numbers 


It is not customary in ordinary mathematics to distinguish between in- 
tegers, fractional and irrational numbers; in fact a good deal of advanced 
mathematics is concerned to remove these distinctions. However digital 
computers work with two main kinds of number representation. The first, 
integers, are used for counting, where an exact result is necessary, as 
for example, in looping through an iterative computation, or referencing 
the elements of an array. Thus all digital computers have a convention 
for storing and handling ‘fixed point numbers’ or integers, where the 
decimal point is at the rightmost end of the number, allowing no frac- 
tional part. 

The other kind of number, the fractional and irrational types (which are 
not distinguished in the machine) cannot be stored accurately. An infinite 
computer would be needed, for example, to store \/2. So we are content 
with a limited accuracy, as specified by a certain number of decimal 
places (though the results of computations do not necessarily give all of 
these equal significance). The representation for such fractional decimal 
numbers is called FLOATING DECIMAL notation. For example, 


314.159265 is written .314159265 x 10? 
or 3141.59265 x 10' or .000314159265 x 10° 


When the decimal point is in front of the fractional part, as in the first 
example above, it is sometimes called STANDARDIZED floating point, 
the form in which it is actually stored in the computer. However any 
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syntactic definition of allowable forms of number should desirably per- 
mit any reasonable form, as given above, with the understanding that the 
standardized form will be the actual form of internal representation. The 
general form of standardized floating decimal representation is 

+m 10° where m is the fractional coefficient (or mantissa), and |m| < 1, 
and e is the exponent or scale factor, which can change to allow the 
condition on m; e is an integer. Storing any number in this form incurs a 
ROUNDING ERROR; if x is the actual number in a d-decimal digit 
representation, and x is the machine equivalent, then the limited space 
to store x‘ means it must be ROUNDED, in a manner defined by 


e=|x- x®|<.5x 109 


The user of a particular computer should ascertain what accuracy he may 
expect for floating point numbers. In quite simple algebraic computations, 
particularly of a repetitive kind, * the errors from rounding may accumu- 
late in such a way as to affect the number of decimal places that are 
significant. Very often heavily worked parts of a program responsible for 
this phenomenon can be separated off into special machine code sub- 
routines specially wsitten to use multiple precision floating point 
arithmetic. '® 


2.2.1 Integer numbers 
We are now in a position to state the first formal syntactic rules for 
Algol 60. Since the simplest form of number is an integer, this is defined 
first, and later incorporated into that for a decimal number, of which it is 
obviously a special case. 

The basic elements of numbers are decimal digits, and these terminal 
productions are defined thus 


(digit) ::= 0]1/2/3/4|5}617(8/9 (2.2) 


From any of these we can now form an Cinteger> as a string of (digit) s, 
thus 


<unsigned integer) ::= digit) | Cunsigned integer) digit) (2.3) 


That is, there must be at least one <digit), or, it must start with a (digit), 
followed by another, and another recursively. To take account of signs, 


we define 
<integer> ::= (unsigned integer) | + (unsigned integer) | 
— unsigned integer) (2.4) 
Example? —- 28 +0 0030 -2 + 60083452 
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2.2.2, Decimal numbers 


The usual alternatives for writing decimals are: .314159265 ( <decimal 


fraction ) ), 219.81992 (< decimal number >), 21.981992 x 10', etc. Thus 
we have formally, 


<decimal fraction) ::= . unsigned integer> (2.5) 
Example 2 .003 rs) -314199 
Cexponent part> ::= ,<integer) (2.6) 
Example 3 1o- O1 1903 1 
<decimal number) ::= Cunsigned integer» | (decimal fraction) | 
Cunsigned integer> decimal fraction) (2.7) 
Exomple 4 305.0 1.0 005.8690 919.456 7 63 


Combining (2.5—2.7) we are now led to define 


Cunsigned number) ::= <decimal number) | «exponent part» | 
(decimal number) exponent part> (2.8) 


Example $ 33.3,9-5 5661946 -00045,,- 03 


This last form includes the others; even though an (integer is 
represented internally in a different way to the (decimal fraction), it is 
included in the definition of (number >. However a “variable in a 

« program), which is specified as an integer quantity, will not normally 
be allowed to have a (decimal fraction) quantity assigned to it. 
Finally, to allow for signs before the coefficient, 


«number :t= Cunsigned number) | + (unsigned number > | 
- Cunsigned number) (2.9) 
Example 6 — 33.3,.-5 ~ 33.3,,04 107 76 
-.7 - 5406 +98 


2.3 Arithmetic variables 


There are two principal kinds of arithmetic variables distinguished in 
Algol 60, as we anticipated in 2.1; the simple unsubscripted type, and 
the subscripted variable, corresponding to vector or matrix representation. 
2.3.1 Simple variables 


The features common to all variables are their name and type as 
expressed in a (declaration) of the variables. The name is formally 
described by an identifier), made up exclusively of (letter) s and 
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<digit>s, as defined in appendix 1. 
Formally we have 


<identifier) ::= (letter) | Cidentifier> letter > | 
Cidentifier> <digit> (2.10) 


An <identifier> must therefore begin with a letter). 


Exomple7 x2 ymax22 aLb2C3 cabbage TTY 
Finally, a simple variable name is defined as 
«simple variable> ::= identifier > (2.11) 


One will normally choose an <identifier>) to name a <variable) which 
is in the application context. 


2.3.2. Array variables 


both A -]j a,, @.2-—« @a, Jand V = [V,, V3, Yj] 
ax, a5. as, 


are non-Algol examples of the use of subscripted variables. For example, 
a set of linear algebraic equations can be conveniently written as an 
an array, in matrix form, though we shall not assume the reader is con- 
versant with matrix algebra, other than in some occasional examples. An 
‘array’ is only a way of representing conveniently an ordered set of 
values, and subscripts can arise in all sorts of ways independently of 
matrices. The Algol 60 syntax for arrays follows matrix nomenclature, 
using a single name for the field of values comprising the array (arith- 
metic or boolean) and each element of the array is referenced by a 
particular subscript value. For example, in the array A above, A de- 
scribes a 3 x 3 matrix of which a typical element might be A, , ; the sub- 
script bounds are defined by the inequalities: 1< i <3, 1<j;<3. The 
dimensionality of /l is simply the number of subscripts, 2 in the case of 
A. V is a I-dimensional array (or vector). T_, 34 9) is an element of 
a 3-dimensional array. 

The formal syntax follows: 


<subscripted variable) ::= (array identifier> [subscript list>] (2.12) 


where 


Carray identifier) ::= identified (2.13) 
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Also 


<subscript list) ::= (subscript expression) | (2.14) 
«subscript list), (subscript expression> 


Finally, 


<subscript expression) ::= (arithmetic expression) (2.15) 


Here for the first time we come up against the inherently recursive 
definition of (subscript expression in terms of ¢ arithmetic 
expression >. Likewise we shall have to define the ¢ arithmetic 
expression ) in terms of (subscripted variables, which in turn imply 

« subscript expression >. There is no escaping this recursion, which 
follows from the requirement to allow each type of expression to appear 
within the other. For the moment the reader will have to assume a 
notional idea of <arithmetic expression>. 


Example 8 x(3] yli+ r{j] x 2] k{t(5]] 


Here we have anticipated that a ¢ subscipted variable > can be part of the 
«arithmetic expression) forming the (subscipt expression > i+ r{j] x 2. 
Having completed the syntax for variables, we may now say that 


variable) ::= (simple variable) | (subscripted variable) (2.16) 


The (arithmetic expression) in a (subscript expression) is understood 
to be rounded to the nearest (integer). 


2.4 Variable declarations 


An important distinction between say Algol 60 and Fortran, is that all 
( variable }s must be explicitly declared in a (program). An asset of 
this is that if a mistake is made in preparing the (program), by mis- 
spelling an (identifier), the Algo! 60 compiler will detect this as an 
undeclared quantity, and some appropriate error message can be output. 
For the present we shall also assume that the ¢ declaration) of all 
< variables occurs at the beginning of the (program) . In fact 
<declaration)s may appear later, giving a facility rather like ‘working in 
the margin’, with certain transient quantities being calculated with the 
aid of temporary < variable)s which cease to exist when this part of the 
‘program > is left. 
The form of a (declaration) is 


arithmetic type declaration) ::= arithmetic type> <type list > (2.17) 


The distinction here between (arithmetic type) s highlights the earlier 
point about the representation of floating point and fixed point (integer) 
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quantities. Essentially any floating point (variable) is said to be of 
type real, any fixed point variable) of type integer, thus 


<arithmetic type> ::= real | integer | own real | own integer (2.18) 


The four terminal productions here are (basic symbols used to prefix a 
« declaration) of appropriate type. Further, the 


«type list) ::= (simple variable > | 
¢simple variable>, type list> (2.19) 
Example 9 real al, Xmax, b2, b3 integer i, k, xx, xy2 


All ¢variable>s MUST be declared in this way. 

The (declaration) of <subscripted variable)s is performed differently, 
with a prefix to indicate it is an array, and with bounds to indicate the 
subscript field limits. 


«arithmetic array declaration) ::= array (array list) | 
“arithmetic type) array <array list) (2.20) 
If no <arithmetic type> prefix is used, the array elements are assumed to 


be of type real. The prefix own has a significance which will be 
explained in 3.5. Continuing, 


array list) ::= array segment > | 
array list), array segment) (2.21) 
Thus a string of (array segment)s is permitted, each being 
(array segment) ::= array identifier) [<bound pair list) ] | 
“array identifier), (array segment > (2.22) 


This permits one or more arrays to have the same dimensions and sub- 
script bounds, as defined by: 


Cbound pair list) ::= (bound pair > | 
<bound pair list>, “bound pair) (2.23) 


The number of entries in the (bound pair list ) is the dimensionality of 
the (array segment). The actual bounds are given by 


<bound pair) ::= “lower bound > : (upper bound> (2.24) 
where 
<lower bound) ::= (arithmetic expression) 
: ; : (2.25) 
<upper bound) ::= arithmetic expression> 
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Example 10 Tmat (3:4, -10:10, 0:5] 
a (0: 200] are all examples of 
t3[n:2x n+ 1] (array segments 
p,q, r({1:6] 


Tmat (3:4, - 10:10, 0:5], a(0:20], t3[n:2x n+ 1], p,q, rl1:6] is 
an example of an (array list). ‘Tmat’ is the (array identifier) of a 
3-dimensional array, ‘a’ that of a vector, ‘t3’ is the ¢ array identifier) of 
a ‘dynamic’ array, i.e., one for which the bounds are determined only at 
execution time, depending on the value of n. 


Esomple 11 array a, b[0:5], c{m:n] integer array p lint: aft] 


The restriction that (lower bound) < (upper bound) at all times is 
required by many compilers. 


2.4.1 Values and types 


The VALUE of a (variable) will depend on its declared type. We shall 
often refer to expressions of a certain TYPE, which could include simple 
«number)s, or expressions, which, by virtue of precedence rules (to be 
defined) have a certain value. This value will find a constant equivalent 
in the definitions of (number). 


2.5 Simple arithmetic expressions 


The basic components of formulae are familiar; a series of terms strung 
together by addition and subtraction signs. The terms are made up of 
factors arising from the raising to a power (exponentiation), multipli- 
cation and division, and operate between basic elements, or primaries 
which may be variables, functions and constants. We give a formal 
expression to these intuitive ideas as follows: 


<simple arithmetic expression ::= term) | 
<adding operator) <term) | 
(simple arithmetic expression) (adding operator) term) (2.26) 
where the 
(adding operator) ::= 4 |- (2.27) 
Further, 
(term) ::= (factor) | (term) multiplying operator) factor) (2.28) 
where the 
(multiplying operator) ::= x | /| + (2.29) 
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The results of these operators are defined in 


El x E2_ is the real product if either El or E2 is real 
but is the integer product if both are type integer. 

E1 / E2_ is always real, even if El, E2 are integer type. 

El = E2_ is always an integer result, which is defined only if El, E2 
are also of type integer. 


The (term>s to be added are made up of <factor)s, defined as 
{factor) ::- primary? | <factor> ft (primary) (2.30) 


Note that the ‘f’ symbol is used with the second form here to denote 
exponentiation; (factor) is the base, and (primary) the exponent. 
Finally, 


primary) ::=- Cunsigned number) | variable) | 
> 
(arithmetic expression) ) | 


Carithmetic type procedure call) (2.31) 


This exhausts the categories necessary to compound quite complicated 
mathematical expressions. Indeed the result may be made contingent upon 
sub-expressions of various types, by the parenthesizing of additional 
« arithmetic expression )s. Complex functions can be written separately, 
as procedures, and activated by the ¢ type procedure call) option. Note 
that only arithmetic variables can appear, although the conditional part 
in parentheses will contain (boolean expression)s and hence boolean 
type <variable? s. 

The <basic symbol)‘+’ is used to indicate integer division, so that 
i + j, where i, j are values (variables, expressions or numbers) of integer 
type, denotes the number of times j is contained in i. A formal definition 
is given in 2.6. 

The operator definitions are grouped, to give 


<arithmetic operator) ::= multiplying operator) | 
«adding operator) (2.32) 


Example 12 3” is written 3 ft x. 


2.5.14. Exponentiation nles 


Let i denote an integer type value, ra real type of value, and x a value 
of either type, then the following scheme gives the results for 
exponentiation: 
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xter 


f= 
defined 


| _undefined | un 


undefined 
0.0 (real) 
exp (r x In(x)) 


exp (rx In(x)) 1.0 (real) 


1 or 1.0 
(type of x) 


1/(x x x..x) to 
-i factors, of 
type real 


xx x..x to 
i factors 


xX X xX...x to 
i factors 


1/(x x x..x) to 
-i factors, of 
type real 


1 or 1.0 
(type of x) 


xX x x..x to 
i factors 


We will shortly explain the ‘standard functions’ exp and In, but observe 
here that exp (E), is always a real result, whatever E is. However, these 
results do indicate precisely how each particular case is computed, once 
the operands are determined. For example 3” = exp(In(3”)), using exp, 
In in their mathematical sense, is computed as exp (x x In(3.0)), so 
nothing is saved by writing it in this manner, with the possible exception 
of the type conversion of 3 (integer) to 3.0 (real), which would be 
implicit if we wrote exp (x x In(3)). This point is discussed in 2.5.3 and 
is a real point in generating efficient programs. Undefined situations will 
usually give rise to output of diagnostic messages. 

Some people, presumably with a mistaken notion of efficiency will 
sometimes write ‘y x y x y’ for y*, where it will however be clear that 
‘y t 3’ computes identically to ‘y x yx y’ 


2.5.2 Brackets and precedence mules 
On first sight, a syntactically correct (expression) like ‘3.85 f x/a’ is 


3.85* 


—— or 3.85%". We therefore adopt 


ambiguous; it could possible mean 


the following precedence convention; the ¢ arithmetic expression) is 
always evaluated from LEFT to RIGHT, and, subject to this, in the order: 
exponentiation, multiplication (and division), addition (and subtraction). 
Thus each <term) is evaluated first, with exponentiations taking priority. 
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Example 13 c —a/b + 3.85 f x/c is evaluated in the following stages: 
(a) a/b is evaluated 
(b) c — a/b is evaluated 
(c) 3.85 tf x is evaluated 
(d) 3.85 t x/c is evaluated 
(e) (c -a/b) + 3.85 t x/c is evaluated 


The precedence order can always be over-ridden by the use of brackets 
(parentheses). This effectively converts any part of an arithmetic 
expression) into a (primary>. Thus a/(c x d —- b) is not the same as 
a/exd-—b. 


2.5.3 Type of result 

If ALL the operands in an “arithmetic expression) are of integer type, 
i.e., not ‘/’ or ‘ft’, then so is the result; however just one occurrence of 
a real quantity ( <variable) or (number) or an implied real result from 
using the ‘/’ operator) will be sufficient to cause automatic type con- 
version to real type. Since this is usually done during the execution 
phase of the running of a program, it pays to ensure at least that all con- 
stants appearing are of the same type, avoiding unecessary type con- 
versions. For example, the (expression) 3 - 5x t/6 will compute as a 
real value, so that the integer constants 3, 5, 6 will all automatically be 
converted to real representation during its evaluation. A simple rule 
which can avoid this is to write any constant appearing in a real 
<expression) as a (decimal) number with a decimal point, thus ensuring 
it is compiled in floating decimal form. Again, an (expression) con- 
taining all integer quantities, will be converted to real if just one 
<number) with a decimal point occurs in it, even if the type of the 
<variable) to which it is assigned (in a (statement>) is integer. The 
same thing happens if the (basic symbol) / occurs in an otherwise 
integer (expression) . 


Exomple 14 In the following, only n, k are integer <variable) s 
(a) c x (a x b- t/3.0) means cab - ct/3, and saves one type con- 
version over the form c x ax b-— cx t/3. This form saves one 
multiplication too 
(b) a/(c x d) means a/cd whereas a/c x d means ad/c 
k 
(c) 3 fn t k means (3°) whereas 3¢(n tk) means 3™ 
Note also that the syntax rules do not permit operators to appear adjacent. 


Thus ax-—b must be written as ax (—b); similarly a f —-2 must be 
written af (— 2). 
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2.6 Standard functions 


We have already observed from (2.1) that certain common functions occur, 
as well as the less common ones such as the Bessel function alluded to. 
Since any component of a (primary) may be an arithmetic type pro- 
cedure statement) (2.31), it may just be necessary to define such 
functions specially, and this is provided for in the syntax for procedures 
in chapter 7. We have to anticipate this syntax if even our early programs 
are to use common functions; again, this is one of the inherently recursive 
situations, since <arithmetic expression) s may contain <procedure 
statement)s, and (procedure declaration) s may in turn contain 
arithmetic expression) s. 

The main difference is that the standard functions do not have to be 
declared — only called. If the reader will consult eqs 7.21, 22 et seq., it 
will be observed that a (procedure statement) corresponding to a <type 
procedure) consists of the (procedure identifier ) optionally followed by 
an (actual parameter part). A <type procedure) always has the option 
that a value can be assigned to its (procedure identifier». In the case of 
procedures to define functions (of one or more variables), the value of the 
function will usually have been assigned to the (procedure identifier) . 

The standard functions of analysis, together with some other useful 
functions, are available to the programmer by means of RESERVED NAMES, 
certain (identifier) s, for example, sin(x) will have their traditional 
meanings, and are available without definition. Though these meanings 
can be over-ridden by redeclaring their (identifier) s in some other con- 
text, in some <block) of a (program) . Thus 


(reserved identifier) ::= sin | cos | arctan | exp | In | 
sqrt | abs | sign | entier (2.33) 


The actual parameter part) (7.2.2.) for the standard tunctions simply 
consists of one parameter, the conventional function argument (or 
independent variable). The standard functions are defined as: 


sin (t) the trigonometric sine of t (radians) 

cos (t) the trigonometric cosine of t (radians) 

arctan (t) the principal value in radians of the inverse tangent of t 
where, S arctan (t) <5 

In (t) the natural logarithm (Naperian) of t (> 0) 

exp (t) the exponential function of t, i.e., e'. 

sqrt (t) the square root of t (t 2 0) 

abs (t) the positive value of t, i.e., |t| 
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sign (t) the sign of t, +1lift>0, Oift=0,-1lift<0 
entier (t) the largest integer value, not greater than t 


Except for sign and entier all these functions yield a real result. Such a 
set of functions is of course minimal for most scientific and engineering 
applications, and in practice many compilers will provide additional 
functions accessible by additional (reserved identifier }s. (Compare 
chapters 8 and 9). 

A properly run computing installation in which Algol 60 is available 
as an efficient computing medium (which is not always !) will have 
available a library “of additional functions which may be called by ar- 
ranging to incorporate them from say, magnetic tape or disc during the 
compilation phase. It may be that this is done by special instructions to 
the operating system via, say, control cards or special job specifications. 
The manual for the installation will define how this is done. 

Some fairly common functions which are not listed above, can be re- 
duced to the standard functions as follows: 


Function Standard function representation 
sin't = arcsin (t) arctan (t/sqrt (1.0-t f 2)) 
cos't = arccos (t) arctan (sqrt(1.0 —- t t 2)/t) 
cosec't = arccosec (t) arctan (1.0/sqrt (1.0 -t t 2)) 
sec't = arcsec (t) arctan (sqrt(t t 2- 1.0)) 
cot 't = arccot (t) arctan (1.0/t) 
sinh't = arcsinh (t) In(t+ sqrt (t f 2+ 1.0)) 
cosh 't = arccosh (t) In(t + sqrt(t [2-1.0)),t 21 
tanh"'t = arctanh (t) i. In((1.0+ t)/(1.0- t)), (-1<t<1) 
cosech 't = arccosech (t) In((1.0 + sqrt(t f 2+ 1.0))/t), t #0 
sech"'t = arcsech (t) In((1.0+ sqrt(1.0-t f 2))/t),O<t<1 
coth"'t = arccoth (t) 1 In((t + 1.0)/(t — 1.0)), t?>1 


2 


Many other definitive formulae for wel! known mathematica! functions 
may be found. 
The (arithmetic operator) + can now be mathematically defined as 


i + j = sign (i/j) x entier (abs (i/j)). 
Example 15 7 +42 ] -7+42+-1] 7+2=3 


The relation (n + 2) x 2 = n is only tme if n is even. 
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Exomple 16 We may now write (2.1) fully in Algol 60 as 


(- 23.0 x (ax arctan(sqrt(p f 2- 1.0))+ bx xx c[1, 2]x In(x + sin(p)) ) 
/(283.86 x j(n, 3.0x p)+ tli, j + k]}) 


The assumption here is that an arithmetic type procedure has been 
written, with the value of the Bessel function of order n left in the 
«procedure identifier) j. 


Emmple 17 (—b + V(b? ~ 4ac))/2a has the Algol 60 representation 
(-b+ sqrt(b f 2~4.0x ax c))/(2.0 x a) 


Example 18 (a) log,,x = (In x)/In 10 has the representation 
In (x)/1n (10.0) 


(b) log,,|cot (x + y) | = log,,| tan(x + y) |" = 
- log,,| tan(x + y) | and has the representation 
-In(abs (sin(x + y)/cos (x + y)))/In (10.0) 


(c) ay + by? + cy? has the representations 
(i) axy+bxy [2+ cx y3 
(ii) yx (a+ yx (b+ yx c)) 


It is worth observing in this last example that form (i) needs 6 multipli- 
cations, while form (ii) requires only 3. Thus from the viewpoint of 
programming efficiency, the nested form (ii) will yield substantial savings 
in time, where the order of the polynomial is large. It is easy to show 

that the n-th order polynomial needs n(n + 1) multiplications as against 
only n for the nested form. Usually multiplication takes longer than 
addition or subtraction. 


2.7 Arithmetic expressions 


The (simple arithmetic expression) considered hitherto can be general- 
ized into a conditional form, in which the actual value taken by a given 
(expression) depends on the truth or falsity of one or more boolean 
relations. 

The generalization is 


arithmetic expression) ::= (simple arithmetic expression) | 
if clause) (simple arithmetic expression) else 
arithmetic expression) (2.34) 
where the 
{if clause) ::= if (boolean expression) then (2.35) 
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The (boolean expression) is not dealt with fully until chapter 6, but 
again this is an inherently recursive situation. The simplest kind of 
{boolean expression? is a (relation). 


Example 19 x+y at+b<3 sin(x |2)<Q are all <relation)s 
or “boolean expression) s which are either valued true or 
false depending on the current values of x, y, a, b, x, Q 


Example 20 if x= y thens+ 1 else s-— 1 is an “arithmetic 
expression ) taking the value of s+ 1 if x = y, otherwise the 
value s - 1. 


Example 21. This kind of arithmetic expression can be enclosed in 
parentheses to render it a <primary> (cf. 2.31). Thus 


y + sin(x + (if x = 0 then pi/2 else 2 x pi)) 
- 3.0 (if k < 0 then r elses) 


2.8 Comments on array variables 


In order to facilitate the writing of EFFICIENT Algol 60 (program) s, 
some observations are worth noting. When an array <variable> such as 
X[5x n+ 2] occurs in an “arithmetic expression >, the target, or 

object “program ) produced by the Algol compiler will add some means by 
which, at execution time, the ABSOLUTE storage location corresponding 
to X[5= n+ 2] can be accessed, and its content (the value of 

X[5 x n+ 2]), entered into the processing of the <arithmetic expression) . 
It is clear that the ‘means’ will have to include a piece of code which 
will compute an absolute array address, given the ¢ bound pair list > in 
the “array declaration». As we shall see in chapter 3, these <bound 
pair) values are permitted to occur within the block structure of the 
<program), a fact anticipated in 2.4, and they can themselves be 
<variable >s. Thus the compiled code will have to in general compute the 
bounds, work out the relative address (to the lower bound on any sub- 
Script), and convert this to an absolute address before the actual con- 
tents of location X[5~x n+ 2] can be accessed. The process can be 
greatly simplified and speeded up for <simple variables) s. 

But this convenient notation for <subscripted variables clearly 
carries with it a time penalty, and the programmer who is after efficiency 
and speed will try to reduce, as far as possible, direct reference to the 
same «subscripted variable>. A convenient way of doing this is often to 
ASSIGN, via a simple Cassignment statement) (next chapter), the VALUE 
of that array variable, as for example ‘XX = X[Sx n+ 2]? and use ‘XX’ 
instead. The single location named ‘XX’ then contains the contents of 
the array location ‘X[5 x n+ 2], and that value can be accessed from 
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‘XX’ far more quickly. A case of this kind occurs in example 5 of 5.4. 
The truth is that the very generality of Algol tends to permit abuse of 
efficiency unless one is careful. 


26 


3 


Statements, Blocks and Programs 


The syntax for constructing ‘arithmetic expression) s of very wide 
variety is now defined, and it is now necessary to give the means by 
which these values are assigned to other <variables)s. This is by means 
of a new metavariable, the “statement >, of which several kinds are 
distinguished. 

It is no doubt clear that equations in the ordinary mathematical sense 
cannot be used. To program a computer to understand the variety of inter- 
pretations of any given mathematical equation or formula would be a 
formidable task, although some languages do specifically deal with 
formula manipulation in a different sense. '*It is far more efficient for 
computational purposes if the variables desired can be formally elimin- 
ated by the programmer, so that explicit mathematical expressions are 
available, which can then be converted by the rules of chapter 2. 

In the case of certain ‘standard’ computational problems, for example, 
the determination of polynomial roots, where formal elimination is imposs- 
ible in general, a computational algorithm will have to be used, in the 
form of a procedure, hopefully provided by a library of such algorithms. 


3.1 Assignment statements 


The syntax of an ¢arithmetic assignment statement) is complicated by 
the provision for simultaneously assigning the same expression) to any 
number of variable) s, in the form 


<arithmetic assignment statement) ::= (left part list) 
arithmetic expression) (3.1) 
where the 
“left part list) ::= (left part) | “left part list) (left part> (3.2) 
and the 
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(left part) ::= variable) :=| “procedure identifier > <= (3.3) 
Exomple] x := a+b Tli] :=+i+3xk  sinx :=y := theta := 0.0 


Notes (a) The “arithmetic type) of all the <variable> s in the <left 

part list > must be the same 

(b) If the (left part list }is of real type and the RHS of integer 
type, then the RHS value will undergo automatic type con- 
version to real before the assignment is made. 

(c) If the <left part list} is of integer type, and the RHS is of 
real type, then the RHS value is converted via the transfer 
function entier (E + 0.5), where E is the RHS value. 


(d) PRECEDENCE 


In order to avoid ambiguity in the interpretation of such examples as 
k := t{k+1] := i+ j, we state the following order of evaluation, or pre- 
cedence 


(a) Any (subscript expression) in the “left part> <variable)s is 
evaluated 


(b) The RHS (expression) is evaluated 


(c) The value of the RHS (expression) is assigned to all the ¢ left> 
part variables 


Example 2 k := t[k +1] t= i+ j where k= 3,i=1,j=-2 is 
evaluated as 


(a)k :=tl4] c= i+j (b)k := tl4) :=-1 (c) k:=-1 tl4] c= -1 


3.2 Compound statements 


It is often necessary to link several “assignment statements (see 3.12) 
in a manner indicating a kind of group statement. This may be done 
formally by bracketing such groups of (statement)s by the (basic 
symbol) s ‘begin’ and ‘end’. The formal syntax is worth studying closely. 

The main definition envisages both labelled and unlabelled 
<statement) s. This means that a particular (assignment statement > may 
optionally be labelled, so that control may pass to it from other parts of 
the (program). Labels are formally defined as: 


(label) ::= identifier) | (unsigned integer) (3.4) 


However, the (unsigned integer) option here is very rarely implemented 
in practice because of compiler efficiency considerations. 
The general form of statement is 
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<compound statement) ::= unlabelled compound) | 
<label> : <compound statement) (3.5) 


This recursive form means that several (label) s can be used for the 
same <“statement), for example, 


L: stop: FAIL: <statement> 


The <unlabelled compound) always starts with a begin, thus, 


<unlabelled compound) ::= begin <statement part> end (3.6) 
where the 
«statement part) ::= statement) | <statement); 
<statement part) (3.7) 


Example 3. begin <statement>; <statement>; statement) end 


L: stop: begin ¢statement>; <statement> end 
There are three kinds of <statement)>, namely 


<statement> ::= unconditional statement) | 


“conditional statement> | <for statement (3.8) 


The last two will be dealt with in chapters 4, 5 respectively. The first is 
elaborated as follows, 


<unconditional statement> ::= “basic statement) | 
<compound statement> | <block> (3.9) 


If the reader feels confounded at this point, it should be noted that the 
idea is to allow (compound statements within “compound statement)s, 
and also to allow the <declaration> of further “variable>s within a 
compound statement > by defining an extension, called a <block>. This 
again is a recursive concept, for we cannot define a construct which may 
appear within itself, indefinitely nested, such as a “compound 
statement», without defining the external structural syntax, and then 
finding that the kernel of our definition, here the «basic statement>?, 
must include again the extemal structural syntax. 


Exomple 4 The ideas may appear a little clearer from the following which 
is allowed by (3.5, 9): 


begin statement); 
begin <statement>; statement) end 


end 
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Any of the “statements occurring in this example can be of the kind 
defined in (3.8). 


There are three kinds of <basic statement), but first we must define 
the optional use of labelling, thus 
“basic statement> ::= (unlabelled basic statement) | 
(label) : “(basic statement) (3.10) 
Exomple 5 begin basic statement> ; 
fig tree: (basic statement) ; 


“basic statement); 


RHUBARB: begin statement); (statement) end 
<statement>; basic statement) 


end 


Finally we have, 


{unlabelled basic statement) ::= assignment statement) | 

<go to statement > | 

<procedure statement) | 

empty) (3.11) 
(procedure statement) s will be discussed in chapter 7, and the <go to 
statement) in section 3.4. Also 
assignment statement) ::= arithmetic assignment statement) | 

(boolean assignment statement) (3.12) 


These were encountered of course in section 3.1, although the boolean 
variety will be encountered in chapter 6. This generalizes the kind of 
asSignment which can be made. The <empty) option above means simply 
that nothing other than spaces, new lines, which have no syntactic 
significance, need occur before the next <delimiter>. 

Exomple9 (a) X := X+.5,.~6; sinx := sin(x) end; 


(b) done: end This illustrates the (empty) option, and is 


often useful where one simply requires to exit from a given 
‘compound statement > 


(CG)? ss :42 
OUT: end 
end; 


end 
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Here a series of three <compound statements is ended. The semicolon 
after the second is optional. 


Example 7. begin x:= x + 1.0; p := sin(5.0x x f 2); 


next: begin x ‘= y; 
MINUS: x := x— 1.0; Q := arctan(x + sqrt(p [{ 2)) 
end 
done: end 


The use of the <label> ‘done’ again illustrates a dummy (statement) . 
Thus a “compound statement) is created simply by writing the begin 
symbol and ensuring it is later matched by a closing end. It is helpful to 
develop the practice of indenting new begin’s in the manner of the 
following examples, thus clearly delineating the matching brackets. 


Example 8 A program) to convert an angle expressed in radians to 
degrees and minutes: 


begin real angle; integer degrees, mins; 
inreal (1, angle); comment a procedure call to input ‘angle’; 
angle := angle x 57.2957795; 
degrees := sign (angle) x entier (abs (angle) ); 
if abs (angle-degrees) 2 59.5/60.0 then 
begin degrees := degrees + 1; mins := 0 end 
else mins := abs (angle-degrees) x 60.0; 


This last (conditional statement) is necessary to allow for the implicit 
‘mins := entier (theta + .5)’ where theta = abs (angle in degrees) x 60.0, 
which takes place when the real RHS expression is converted to the 
integer type of ‘mins’. Numerical considerations like this are often an 
essential part of the problem analysis. 


Example 9 A program) to input three sides of a triangle, a, b and c, 
and to output the angle opposite side a, and the area. Certain 
input-output procedures will be assumed, the functions of 
which will be obvious; full definitions are given in chapters 
8 and 9. 
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begin real a, b, c, A, sinA, cosA, area; integer deg, min; 
input 3(1, ‘’, a, b,c); cosA := (bf 2+ef 2--a f 2)/(2.0x bx c); 
sinA := sqrt (1.0— cosA } 2); 
if cosA = 0.0 then A := 90 x sign (sinA) else 
A := 57.2957795 x arctan (sinA/cosA) + (if cosA > 0.0 
then 0.0 else 180.0); 
deg := sign (A) x entier (abs (A)); 
if abs (A — deg) > 59.5/60.0 then 
begin deg := deg+1; min := 0 end 
else min := abs (A - deg) x 60.0; 
area := bx cx sinA x .5; 
output 3(2, ‘’, deg, min, area) 


end 


It may be clear that the format of the results when output by ‘output 3’, 
since they are unspecified, are in a standard form, consistent with the 
types of the quantity appearing in the list of actual parameters. For 
further information, consult sections 9.2, 9.3 of chapter 9. 

We should also observe perhaps that although, in section 2.4 we con- 
sidered the FORM of declarations of <variable)s, it is left to section 3.3 
to discuss the exact order of their appearance. 

Again this last example contains an instance of a ¢conditional state- 
ment>, without which very little sensible programming can be done; these 
are fully discussed in chapter 4, although their existence was anticipated 
in (3.8). 


3.3. Blocks and programs 


The (block) is an essential element in the overall structure of a 
(program), but before discussing its formal syntax, it is profitable to 
mention briefly what the overall objective, in terms of (program) struct- 
ure, will be. 

A program) consist of groups of (statement) s which operate on 
<variable)s declared either at the beginning, or at some internal level. 
These levels will be defined as essentially (compound statementD s, 
which, after their initial begin symbol, have one or more new variable)s 
declared. Thus a <compound statement), with <declaration» s added (in 
a manner to be prescribed) is, in a sense, a self-contained piece of 
program) text, and called a <block). It is self-contained in the sense 
that it may operate entirely on (variable) s declared locally, inputting 
their values from calls of input-output procedures, as we anticipated in 
example 9. 
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The formal expression for <declaration) is 


(declaration) ::= <type declaration) | array declaration) | 
<switch declaration) | <procedure declaration)(3.13) 


where 
<type declaration) ::= arithmetic type declaration) | 
“boolean type declaration > (3.14) 
and 
“array declaration) ::= (arithmetic array declaration) | 
<boolean array declaration > (3.15) 


The boolean array declaration) occurs in chapter 6. 

It is of interest to observe that since a “block > is very similar to a 
{compound statement ), we might expect the definition to follow closely 
the example of (3.5, 6, 7). In fact, again anticipating the need to label a 
<block>, we shall have 


<block> ::= unlabelled block) | <label> : (block> (3.16) 


Further, the 


Cunlabelled block) ::= begin declaration part); 
statement part > end (3.17) 


The <statement part ) was defined in (3.7), and the 


<declaration part) ::= declaration) | declaration) ; 


«declaration part) (3.18) 


Evidently the <declaration >s must all come first, followed by the 
«statements. 


Example 10 begin real x, y, YO; integer n; input 1(1, ‘’, n); 
k :=n; 
B: begin array V[-n: 2xn+1]; integer array p, q(0: 50]; 


Cr 


2 


end 
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Exomple 11 L: begin real x, y; 


X := 16+ cos(s); y := r—sin(S); 


tho := sqrt(x f 2+y f 2) 


Note here that the <variable)>s r, s, rho are said to be GLOBAL to the 
<block) labelled ‘L’, since they must have been declared outside it. 
Again, x, y are said to be LOCAL to the (block) ‘L’; they constitute 
temporary ‘workspace’, and once the business of computing ‘rho’ is com- 
pleted, and <block)> ‘L’ is left, the machine locations used to store x, y 
can be re-used in any subsequent (block). This feature of Algol 60 is 
often known as DYNAMIC STORAGE ALLOCATION, and clearly leads 
to much smaller program Ds, provided only that the programmer is pre- 
pared to make use of it when designing his algorithm. 

A (block > is virtually a self-contained program ) since it can contain 
ALL its necessary <variable)s, with internal <statement)s, and even 
other <block)s. We are therefore ready to define a program) , 


(program) ::= (block) | (compound statement) (3.19) 


Example 12 program) to read the data (variable)s x, y, t, u, V and 
compute the formulae u,= V(600- x)/r, v,= V(ur-y)/r 
where r = \/{(ut ~ y)? + (600 - x)?} 

begin real x, y, t, u, V, ux, vx; input 5(1, ‘’, x, y, t, u, V) 
begin real r, temp1, temp2, temp3; 
templ := ux t~-y; temp2 := 600.0 - x; 
r:= sqrt (templ f 2+ temp2 ft 2); temp3 := V/r; 
ux := temp3 x temp2; vx := templ x temp3; 
end; 
output 3(2,‘’, ©, ux, vx) 
end; 


Example 13. To evaluate the expressions p = a? sin x — b 


(In b+ sin x)'? 
q = a + b° - bx, r=a®* cosec x + b exp(In b+ sin x), 
s = In|a? + b°| - xa+ 10. 
In view of the repeated occurrence of the expressions 


In b+ sin x, a°, and a° + b? we could increase efficiency by 
creating two “block)s, as follows: 
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LO : begin real a3, b3, Inb, sx, p, q, r, 8; 
a3 := a f{ 3; Inb := In(b); sx := sin(x); b3 := b [3; 
s := 10.0; 


Li : begin real s; s := Inb+ sx; 
p := a3xsx-b/ sqrt(s); 
r:= a3/sx + bx exp(s) 

end; output 2(2, ‘’, p, 1); 

L2 : begin real ss; ss := a3+ b3; 

q :=ss-— xx b; 


s := In(abs(ss))-xxats 


The <block> Li here affords an example of the re-declaration of the 
Cidentifier> ‘s’. Outside <block> ‘L1’, ‘s’ has the meaning of <block) 
‘LO’, but within (block) ‘L1’ ‘s’ has the name of a new (variable), i.e., 
inside this <block) ‘s’ is the name of a totally different storage location 
to the ‘s’ of <block> ‘LO’. This ‘s’, which was assigned the value 10.0, 
is recovered again in (block > ‘L2’, where it is needed to compute the 
added factor to ‘s’ in the very last ¢statement>. 


3.4 Go to statements 


The normal sequence by which (statement)s in a (program) are execut- 
ed is one after another, in order of occurrence. There are three ways to 
break this sequence: 


(a) via the (goto statement), occasioning a branch to another speci- 
fied «statement > which is labelled; 


(b) via a ¢ procedure statement >, causing an entry to a previous piece 
of the <program> which can be self-contained, analogous to the 
subroutine of lower level languages; 


(c) via a “conditional statement >, when several altemative 
<statement)s may be presented in an elegant form, the precise 
choice depending on the truth or falsity of one or more “boolean 
expression) s. 


From 3.5 et seq., it is evident that any (statement > may be labelled 
optionally, and therefore a goto statement > will simply be a means of 
transferring control either directly, or indirectly, to that <statement>. 
However, the desirability of including some facility for computing a 
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(label) destination DYNAMICALLY, and not merely by direct specifi- 
cation of it, leads to a kind of generalized expression, the value of which 
is defined to be an actual (label); this is called a <designational 
expression». Thus we have 


(goto statement) ::= go to <designational expression) (3.20) 


A particular instance of this definition is 
<simple goto statement) ::= go to <label> 


where <label> was defined in (3.4). This illustrates also exactly what 
the more general (designational expression ») encompasses. The effect 
of a (goto statement) is always to effect a jump to a <labe!> , either 
directly specified, as in the (simple goto statement), or indirectly, as 
in the general case. In the general (goto statement), an Cexpression> 
may be used which will evaluate with a (label) result. This allows more 
complicated branching within a ¢ program). 

In the general case we have that a 


<designational expression) ::= <simple designational expression) | 
<if clause> 
(simple designational expression) else 


(designational expression) (3.21) 


The Cif clause) is the same as in (2.35). However the immediate task is 
to define the various types of basic (goto statement>, as allowed for in 
the (simple designational expression). The direct specification alluded 
to refers to an actual (label), but in the indirect mode, the <label> 
destination is computed dynamically, and will usually depend on the 
current values of (variable) s occurring in the (program) and the 
(designational expression). For the purpose of actual <label> reference 
in such cases, the (label)s are thought of as an array, or perhaps better 
as a 1-dimensional array, or label-vector, with each element of the label- 
vector being numbered 1, 2, 3, ... the upper limit being dependent on the 
number of (label)s. A (label) used in this way has to be declared by 
means of a (switch declaration) in which all the (label) s likely to 
occur as a result of computations of <designational expression) s (in the 
scope of the (block) in which the <switch declaration > occurs) are 
listed, thus establishing the correspondence between names of (label)s 
and their position in the label-vector. This dynamic use of <label)s is. 
referred to in the metalanguage as a SWITCH, so that the elements of the 
label-vector are formally described as the (switch list), and the array- 
like elements are called the (switch variable) s (<switch designator) in 
the Revised Report). Thus, formally, 
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<simple designational expression) ::= (label) | “switch variable) | 


( <designational expression)) (3.22) 


The <label) was defined in (3.4). Otherwise we have 


<switch variable> ::= «switch identifier) 
[ <subscript expression) ] (3.23) 
and the 
switch identifier) ::= identifier) (3.24) 
Example 14 go to finis go to L3 


These two illustrate direct specifications, as given by (3.21). Neither 
<label> s ‘finis’ or ‘L3’ need to be declared in this context. 


Exomple 15 go to ss(5]. Here ss[5] is a <simple designational 
expression) referencing the fifth (label) in a “switch 
declaration). (see 3.4.1) in which ‘ss’ is the “switch 
identifier) 


Example 16 go to ROOT TYPE[2+ sign(b [ 2- 4x ax c)]. This is an 
example of a conditional <designational expression) , for the 
standard function ‘sign’ of 2.6 takes the value + 1 if b? < 4ac, 
0 if b* = 4ac, and - 1 if b? > 4ac. These values will cause the 
«subscript expression) to respectively take on the integer 
values 3, 2, 1 thus causing a branch dynamically to the 
appropriate <label>. Use is made of this device in 


Example 17. As an example of the conditional form in (3.21) we have 
go to if x < 0 then L4 else LS 


Again, while we have not yet dealt with conditional syntax, it is worth 
showing some additional allowable forms: 
go to if t+ 2 > 5.0 then OUT else 

if r 1 2= p then L2 else ROOT TYPE [2- sign(b | 2-4x ax c)] 


go to LIST [if x <0 then 1 else p+ 1] 


3.4.1 The switch declaration 

The previous section showed how indirect “label> references are made 
by means of a “switch variable), in an analogous manner to array 
variables. This section shows how these special (label) s are declared, 
by means of a (switch declaration) . The form is 
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Cswitch declaration) ::=-switch (switch identifier). 
t= «switch list) (3.25) 
where the 
<switch list> ::= (designational expression) | (switch list, 
(designational expression) (3.26) 


In the more common type of ‘switch list>, one would simply have a list 
of labels which are the destinations of <statement)s in some (block) 
might arise in a <goto statement). The (subscript expression) in such 
a (statement) would then be evaluated dynamically in the course of 
execution, and would cause control to pass to one of the (labels speci- 
fied in the switch list). 


Example 18 begin switch hifi := lo, mid, hi; 
Ait ls eh eet ard tl ng mid 
go to hifi(n+ 1]; 
REE ep a Se oes LO? cord so st 
out: 
end 
Here hifi [1] is ‘lo’, 
Example 19 To sum the convergent series 1 + 1/27+ 1/3°+ ... 1/n? +... 


for as long as the general term 1/n? is greater than some 


absolute tolerance ‘eps’. So if eps = .5x | 8 we should get 


the sum to infinity correct to 8 decimals. 


begin real SUM, TERM; integer n; switch next := ADD, OUT1, OUT2; 
n:=Q0; SUM := TERM := 0.0; 

ADD :n:=n+1; TERM := 1.0/n { 2; 
SUM := SUM + TERM; 
go to next [2 - sign (TERM—EPS)]; 

OUT1 : OUT2: output 2(2, ‘’, SUM, n) 

end 

Note here that while TERM<EPS control retums to the (label) ‘ADD’, 


otherwise control passes to-‘OUT1’ or ‘OUT2’. It is necessary to 


specify three (label) s since 3 possibilities exist for the value of 
*TERM—EPS’. 


Exomple 20 To input the coefficients of successive quadratic equations 
ax* + bx + c = 0 and output the roots. 
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begin real ri, 2, il, i2, a, b, c, d; 
switch root type := REAL, EQUAL, COMPLEX; 
next : input 3(1, ‘’, a, b, c); 
if a= 0 then 
begin rl := —c/b; 12 := 0.0; il := i2 := 0.0 end; 
d:=b{2-4.0xaxc; 
go to root type [2 - sign(d)]; 
REAL:rl := (b+ sqrt (d))/(2.0 x a); r2 = (b- sart (d))/(2.0 x a); 
il :=i2 := 0.0; go to finis; 
EQUAL : rl := 12 :=~b/(2.0x a); il := i2 := 0.0; go to finis; 
COMPLEX : rl := -- b/(2.0 « a); il := sqrt (~d)/(2.0 x a); 
r2 := rl; i2 := il; 
finis : output 4(2, ‘ ’, rl, r2, il, i2); 


go to next 


end; 


3.4.2 Scope of labels 

The use of <label)s in <goto statement)s requires some further qualifi- 
cation, in the light of the structure of ¢block)s. Generally, if a 
<variable) is declared in a (block >, then that (block), together with all 
<block)s within, i.e., nested <block)s, constitutes the SCOPE of that 
<variable>. This arose already in example 13, where we saw that one 
could over-ride this by redeclaring the same (identifier > in such a nested 
€block >. 

The (label) s are a somewhat different metavariable, in that they are 
not specifically declared, unless it is intended to use them in a ¢switch 
statement >. The convention therefore is that the scope of any label > is 
understood to be that of the smallest embracing <block>. 

Consider the following: 
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B1 : begin real x, y; 


oe we ee 


EL is. 


| i eer go to L1; 


oe oe © ee 
oe ee ee 


oe eo ee 


Some observations about this sketch (program) will help to clarify 
matters. First of all it is correct. L2 has B2 as its scope (Bl, B2, B3 
are (block) labels). Thus no <goto statement) outside B2 could 
legally lead to L2 — jumps to this «label > can only occur from within 
B2. However a “goto statement) such as go to L1 may lead to a desti- 
nation outside B2. 

No jumping into <block)s is permitted for the simple reason that 
unless one passes through the (declaration part), some (variable)s 
could turn out with undefined values. 

The (variable) ‘y’ means an integer value in (block) B2, where its 
real connotation (form <block) B1) is suspended until B1 is left, when 
the original (real) connotation, and value, is recovered. Any reference 
to ‘y’ in B2 will mean some value defined in B2. However, y will mean 
real in the context of B1, when B3 is entered, for y is not redeclared 
here. 


None of these <label) s could be used OUTSIDE B1. 


3.5 Own variables 


The definition of <block> and (declaration) have made it clear that, 
once a given <block> is left, the (variable>s local to it lose their stor- 
age allocation. Thus on re-entry, they must be recomputed. However, any 
< variable ) declared with a prefix own will retain its value on exit from 
its <block>. 
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Relations and Conditionals 


The constructions so far developed avail us little if we have no con- 
ditional clauses which permit the testing of “expression s against one 
another. The intrinsic fact about a mathematical relation of the kind 
axb+cis that it is either TRUE or FALSE, depending on the current 
values of a, b, c, so that conditional expressions are themselves vari- 
ables of the logical or boolean calculus. 

At this stage no attempt will be made to fully define such boolean 
<variable>s or their manipulation by means of boolean operators. 
However, certain constructs of a “boolean expression), defined in 
chapter 6, called <relation?s are vital to our needs in manipulating 
Carithmetic expression)s, and we treat these separately. 


4.1 Relations 


The testing of a “relation) is performed using the conventional mathe- 
matical symbols, so that 
relational operator ::= <|< | = |>|2\|4 (4.1) 


A relation) is then simply defined as 


(relation) ::= (simple arithmetic expression) (relational operator) 
(simple arithmetic expression) (4.2) 
Example)! XS y+z sin(x) > sin(y[i] x t) a+b # c+d 


4.2 Conditional arithmetic expressions 


We have already noted, in 2.7 (2.34,35) the main features of this, which 
we can recall in slightly varied form, as follows, 


“arithmetic expression) ::= «simple arithmetic expression) | 


<conditional arithmetic expression) 
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where (conditional arithmetic expression) ::= <if clause? 
«simple arithmetic expression) else <arithmetic expression) 


and, again, <if clause) ::= if (boolean expression) then 


Thus the (arithmetic expression > following the else may optionally 
contain further “conditional arithmetic expression) s. 


Exomple2 if x 2pi/2.0 then sin(x) else sin(x + 2.0 x pi) 


It is worth observing that only the option or alternative chosen by the 
(relation) are actually evaluated, NOT BOTH. 


Exomple3 y:=ifp>q+rthenx f 2+ 3.0 else 
ifp<q+rthenx f 2+ 2.0 else 0.0; 


Example 4 afi, j):=if i<j then Q else 
ifi>j then 2 x Q else 
ifi=3 then-Q else 1 


The matter of layout in such <statement)s is a matter of pure con- 
venience, but a symmetric scheme like this often helps to isolate 
mistakes. 

It will be recalled, from (2.31), that this conditional syntax can be 
used within a (simple arithmetic expression) provided only that it is 
Suitably parenthesized, as exemplified in the following examples. 


Exomple5 r:=ifk #2 x i then (if x > 0 then In(x) else —inf) else —2 x i; 
Exomple6 Y:=xX:=x+Ssin(ift >O then t else pi/2.0 + theta); 
Example 7 Z:=R+(ifi>j thens +1 else~s —1)+T; 
Exomple8 A matrix A of order n is to be formed and output, where 
a, =lifi¢n,ay=(-1)'"'ifi>jorj =n, and a,,=Oif 
i<jandj¥¢n 
begin integer i, j, n; ininteger (1, n); i : = 0; 
begin integer array A[1:n, 1: n]; 
Li: j:=0;i:=i41; 
if i > n then go to out; 
L2: j:=j+1; 
Ali, j) := if i>j then (-1) + (i+j-l else 
if i<j then 
begin if j #n then 0 else (-1) t (i +n-—1) end 
else ifi¢n then 1 else -1 
go to if j <n then L2 else LI; 
out: outarray (2, A); 
end 
end; 
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The reader might observe a neater expression of this problem is given in 
example 10 of chapter 6. 


4.3. Conditional statements 


The aim of the “conditional statement > is to permit the execution of any 
number of alternative <statement>s subject to the truth or falsity of any 
number of “boolean expression) s. The construct is analogous to the 
conditional arithmetic expression). It is defined in terms of the other 
“statement > constructs of 3.2 as follows, 


<conditional statement> ::= <if statement> | <if statement? else 
<statement> | “if clause) for statement) | (label) : 
(conditional statement) (4.3) 


where (if statement) ::= <if clause) unconditional statement) (4.4) 


There are thus only two distinct kinds of “conditional statement), the 
first, given in (4.4) in which the option, but no alternative statement 
is given, and the second where both are defined. We already defined in 
(3.8) that a <for siatement ) was a particular kind of <statement)>. The 
fourth class in (4.3) permits any of the previous three to be labelled. 

The main difference between the <conditional statement), and 
«conditional arithmetic expression) of 4.2 (and 2.34) is that the else 
symbol must always be present with arithmetic expressions, whereas 
it is optional with the conditional statement). 


Example 9 if term < y—8 then goto finis; 
Note that the semi-colon is explicitly permitted by (3.7), of 
which (4.3) is of course a special case. 


Example to if x < y + 10.0 then x :=x4+1.0 else x :=x- 1.0; 


Exomplo 11 L: if x < y+ 10.0 then 
beginx:=x-—1; y:=y+1 end else 
x+1;y:=y-1 end; 


u 


begin x: 


Example 12 Sum ot series ) 1/n? for n = 1..200 
sum series: begin real sum, term; integer n; 
sum := 1.0; n:=0; 
ADD: n:=n+1; term:=1.0/nf 2; 
sum := sum + term; 
if n < 200 then go to ADD; 
end; 
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Example 13. A set of (number)s is listed on a deck of cards. We give a 
< program) to read them in, and select the minimum and maximum. There 
are supposed to be m «number )s. 


begin real x, min, max; integer n, m; input 2(1, ‘’, m, x); 
min :=max:=X; fis 1; 
next: input 1(1,‘’, x); 
if x < min then min := x; 
if x > max then max : = x; 
ni=n+1; 
if n <m then go to next; 
output 2(2, ‘’, min, max) 
end; 


4.3.1 Sequencing of conditional statements 


An immediate deduction from (4.3) is that the (statement) following 
else can itself be a “conditional statement), so that several 
(conditional statement)s may be written sequentially. 


Example 14 if x <y then P :=-1 else 
ifx =y thenP :=O else P:=1; 


One could write this alternatively as a (conditional arithmetic 
expression), in the form 


P :=ifx <y then-1 else if x =y then 0 else 1; 


Exomple 15 if X < min then min : = x 
else if x > max then max: 


i] 
ba 


This has the same effect as example 13. 


Exomple 16 if i2 >10 then go to OUT else 
begin if i= 10 then output 1(2, ‘’, i+ k); 
go to OUT 
end; 


It is sometimes useful to be able to test further “relation s in 
sequence, i.e., no specific action is taken unless a number of 
(relation)s are simultaneously true. This is conveniently invoked by 
the realization that though in (4.4), an “unconditional statement) 
MUST follow then (of the ‘if clause) ); one form (3.9) of the 
Cunconditional statement ) is a ‘compound statement ), which may 
again contain (conditional statement) s (from 3.6 and 3.8). All that is 


needed is to enclose the ‘conditional statement) with begin, end, thus 
turning it into a (compound statement). 
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Example 17 if Q = 0 then 
begin if P = 0 then RATIO := 1.0 else RATIO := ,,77 end 
else RATIO : = P/Q; 


This permits the ratio p/q to be evaluated without risking overflow when 
dividing by zero. The (number? ,,77 is assumed to be the largest which 
can be held, i.e., the machine infinity for a particular computer. 


Exemple 18 To set the Cidentifier> ‘all zero’ to 1, if and only if, 


a=b=c=0(a, b, c can be assumed integers) 
ifa = 0 then 
begin if b= 0 then 

begin if c = 0 then all zero := 1 end 
end; 


To show the capabilities of boolean variables, we could alternatively 
express this as 


ifa=0 A b=0 Ac =O thenall zero:=1 


For interpretation the reader should consult chapter 6. 
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The need frequently occurs to execute a single, or “compound statement) 
several times, iteratively. This happens, for example, with ‘array 
variable>s, or <expression>s containing them which must be executed 
for all elements. 


Example 1 To input and sum the elements of the vector array a,, where 
-20< 1: < 20 
begin array a(— 20: 20]; inarray (1, a); 


comment the procedure ‘inarray’ inputs all the elements of a from 
peripheral device number 1; 


begin real sum; integer i; 


sum :- 0.0; 


if i> 20 then go to out 


else sum := sum: al(i]; 
i:=i+1; 


go to loop; 


We leave this example incomplete, the dots indicating there is more to 
come. It is worth observing the stages of the outlined area of this piece 
of program. They are: 

(a) installization of the ‘loop <variable>’ i; 

(b) testing the range of the subscript value, i; 

(c) executing the sum; 

(d) incrementing the loop «variable> i; 

(e) return to (b). 
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The <for statement > syntax is in effect a shorthand notation enabling 
us to rewrite the boxed-in segment of the program above in a very much 
more compact form (see example 3, section 5.2). 

All this is tedious, and gets very involved when several dimensions 
are involved. Therefore a special construct, the (for statement > is pro- 
vided, which does the initialization, incrementing and range testing auto- 
matically, subject to certain information being provided. 

Any “statement which it is required to iterate in this way is charac- 
terized by a loop variable. The syntax follows : 


(for statement) ::= “for clause» statement) | 
(label) : “for statement > (5.1) 


This is the usual option of both labelled and unlabelled constructs. 
Further: 


<for clause) ::= for “variable? := for list» do (5.2) 


The <for list) is defined in the usual recursive manner, so that a single 
for list element) or several, separated by commas, is permitted, 


(for list) ::= for list element > | 
(for list, “for list element (5.3) 


The action of (5.2) is to initialize the loop variable to the first for list 


element, and then proceed as specified by the <for list ) construct, as 
follows, 


for list element) ::= (arithmetic expression) | 
<step-until element) | <while element) (5.4) 
The first of these is evidently of the form 
for <variable> := “arithmetic expression) do statement > 


although (5.3) permits a list of “arithmetic expressions >, which are 
understood to be executed sequentially from left to right. The other con- 
structs of (5.4) are, 


(step-until element) ::= arithmetic expression) step 
arithmetic expression) until 
arithmetic expression) (5.5) 


Writing AE for (arithmetic expression) and S for “statement >, this 
evidently permits us to write 


for (variable) ::= AE step AE until AE do S 
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Finally, there is 
<while element> ::= arithmetic expression) while 
“boolean expression) (5.6) 


Returning to (5.2), the general interpretation of a <for list>, which may 
contain admixtures of (5.4, 5, 6) is that they are taken in sequence from 
left to right, as the values of the for-loop variable. A jump out of the 
<statement> controlled by the for-loop will leave the loop variable with 
its value on exit. However, exhaustion of the (for list> is defined to 
leave the loop variable undefined. 

A convenient way of describing the exact function of the <for 
statement), is to elaborate it in terms of simple Algol 60 constructs, i.e., 
to reduce it to CANONICAL FORM. For the sake of this explanation we 
shall let E, F, G, denote «arithmetic expression>s, V the loop 
< variable>, and B the “relation> in (5.6). Also S denotes a general 
«statement >. 


5.1 Expression elements 
Using (5.1, 2, 3, 4) some typical forms are 
for V := E do S; 


which is equivalent to: V := E; S; 
Also for V := E, F, G, do S is the same as 


V := F; S; V :=F; §; V:= GS; 


5.2 Step-until elements 
The general form is 

for V := E step F until G do S; 
and is equivalent to: V := E; 


TEST : if (V -— G) x sign (F)> 0 then 
go to OUT else S; 
V := V+ F; go to TEST; 
QUT kee ce ee ede ee 


One can mix the (for list element) s, as for example 
Example 2 fori := 0, 5 step —-2 until —01,-99 do ali] := i/(i+ j) 


Multiple elements can occur: 
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for V := El step F1 until Gi, E2 step F2 until G2, 
E3 step F3 until G3 do S 
has the same action as: 
for V := El step FI until G1 do S; 
for V := E2 step F2 until G2 do S; 
for V := E3 step F3 until G3 do S; 
Exomple 3 We can now illustrate the compact nature of this notation by 
rewriting example 1 of this chapter. 
begin array a(-20: 20]; inarray (1, a); 
begin reo! sum; integer i; 


sum := 0.0; 


~20 step 1 until 20 do 


sum + alil; 


fori: 


sum : 


ee ee 


The ‘out’ and ‘loop’ labels of example 1 are no longer necessary although 
they are implied in the execution of the “for statement >. The boxed 
section is formally identical in function to that of example 1. 


5.3 While elements 
The general form is 
for V := E while B do S 
which is equivalent to 
LOOP: V := E; 
if B then S else go to OUT; 
go to LOOP, 
OUT ~ 4.28 tein ao ans 
Example 4 for V := E, F, G while B do S_ is equivalent to 
V:= E; S; 
V :=F; S$; 
for V := G while B do § 


Jumps must not be made into a for statement) from outside, as this 
could result in the loop ‘variable) being undefined. 
Notice also that, from (3.8) the “for statement) now joins the 
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general class of (statement). It is therefore possible for the ¢« statement) 
‘S’ used in the previous examples to be itself another <for statement). 
In fact the form 

for V := E step F until G do 

for VI := El step Fl until G1 do S 


can be written equivalently as 


for V :=E step F until G do 

begin real undefined; V1 := El; 

TEST : if (V1 - G1) x sign (F1)> 0 then 

go to OUT else S; 
V1 := V1+F1; goto TEST; 

OUT : V1 := undefined 

end; 
This example affords an illustration of a “compound statement) controll- 
ed by a for-loop. If one tries to elaborate the outer for-loop via the method 
of 5.2, the convenient shorthand of this notation becomes quite apparent. 
The for-loop with its three kinds of element express very concisely all 
the basic facts about an iterative process: initialization. increment and 
terminal condition. 


5.4 Some applications 


Example 5 To input n real (number) s and print out their mean, and mean 
sum of squares. 
begin integer n; input 1(1, ‘’, n); 
begin array X[1:n]; real sum, sumsq; integer i; 
sum := sumsq := 0.0; 
for i :- 1 step 1 until n do 
begin input 1(1, ‘’, X{i]); 
sum := sum+ X[i]; sumsq := sumsq+ X[i] ¢ 2 
end; output 2(2, ‘’, sum/n, sumsq/n) 
end 


end; 
The reader may observe that this example is most inefticiently programmed. 


Array <variable> s, as we commented in 2.8, are very easy to abuse, and 
this example contains in fact a totally redundant reference to them. The 
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example could quite as well have been written 


begin integer n; input 1(1, ‘’, n); 
begin real sum, sumsq, X: integer i; 
sum i= sumsq := 0.0; 
for i := 1 step 1 until n do 
begin input 1(1, ‘’, X); 
sum := sum+ X; sumsq := sumsq+ X f 2 
end; 


oe © © ee eee ee 


Example 6 To form the product of two rectangular arrays A, B and store it 
in array C. We shall assume the input—output procedures of 


chapter 9. 
begin array A[1:6,1:5], B[1:5,1:3], Cll: 6,1: 3]; 


comment the product is determined by the general formula 


5 
CG; = i An Byj 5 
k= 


integer i, j, k; 
inarray (1, A); inarray (1, B); 
for i := 1 step 1 until 6 do 
for j := 1 step 1 until 3 do 
begin C[i, j] := 0.0; 
for k:= 1 step 1 until 5 do 
Cli, j] := Cli, j) + Ali, k] x B[k, j] 
end; 
outarray (2, C); 
end; 


Again, an efficiency observation: the k-loop above could be speeded up 
by writing it as 
for k := 1 step 1 until 5 do 
ec := c+Ali, k] x B[k, j]; Cli, j] := ¢ 
end; 
outarray (2, C); 
end; 
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This way the (redundant) references to C[i, j] which occurred in the 
first version above are eliminated, leaving only one reference to it in the 
i, j for-loop. The ‘variable> c would of course need to be declared in 
one of the preceding <block)s and set to zero. 


Exomple 7. To compute the sum 


a 


x2 
~cosh x = 1- > + 


x a - Soy oy 19" 


.. ad inf. 


an 
! 


x 
(2n)! 


an 
The general term u,(x) = GC 1y = yi is better expressed recursively in 


terms of preceding terms via the relation u,,,= ~ x? u,/(2n + 2)x (2n+ 1, 
U = 1. This facilitates more efficient computation of successive terms 
without each time evaluating a factorial expression. Whenever this can be 
done for series summation it is preferable, though not without dangers of 
numerical rounding error accumulation. '* The method used is to accumu- 
late the partial sums via the relation s, = s,_, + %,(x), for n= 1, 2, 3, ... 
continuing for as long as the general tem is significantly different from 
zero. Any convergent series like this will have its terms decreasing 
monotonically to zero. 


begin real sum, term; integer n; 


term := 1.0; sum := 0.0; 


for n := 1, n+ 2 while abs(term) > eps do 
begin sum := sum+ term; 

term := -termx x f 2/((n+ 2)x (n+ 1)) 
end; 
output 1(2, ‘’, sum); 


500, 
Example 8 To sum the finite series Y b, excluding those cases where 
k=O 


k = $1, 99, 110 


begin real s; integer k; 
for k := 0 step 1 until 50, 
52 step 1 until 98, 100 step 1 until 109, 
111 step 1 until 500 do s := s+ blk]; 
outreal (2, s) 


end; 
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5.5 Dummy for statements 


The definitions of 5.2, 5.3 yield, implicitly, information about the con- 


ditions under which the controlled <statement? is, or is not executed. 
Considering 


for V := E step F until G do S; 


it is evident that S will not be executed if V> G and F>O orif V<G 
and F < O. For example, the ‘for statement) 
for i := j step p until 20 do a{i] := i I i; 


would not execute ‘a[i] := i { j? if j= 20, p> 0, orif j > 0 but p< 0. 
In such cases the for-loop is executed, but not the controlled 


< statement) ; consequently we refer to such as a dummy (statement). 
Another example permitted is 


for i := 1 step 1 until n do; 


Here no controlled ¢statement> other than “empty) (see 3.11) appears. 


This has its uses, particularly in timing Algol constructs within a for- 
loop to measure their relative speeds of execution. © 
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With the definition of <relation> and relational operator) of chapter 4, 
we have a means of interrupting an instruction sequence by means of 
simple tests via the <conditional statement > or (conditional arithmetic 
expression) of 4.2. However, rather than try to obtain a coincidence of 
<relation)s by the means of 4.2, i.e., successive if’s, it is useful to 
extend the syntax and permit the combination of ¢relation)s by the rules 
of the boolean or logical calculus. 

We may then build up < boolean expression)s which consist of 
<boolean variables operating on each other with the boolean operators, 
in a similar fashion as for the < arithmetic expression>. 

First we must define the 


“boolean value) ::= true | false (6.1) 


Thus any “boolean expression) must be a rule for computing a «boolean 
value). Likewise a boolean value? has no place in an “arithmetic 
expression) specifically as a <primary>, but may be a component in the 
“conditional arithmetic expression>. 


6.1 Boolean operators 


Just as with “arithmetic expressions, “boolean expression) s are built 
up from primary elements and joined by operators of a special kind. Since 
the values of the operands can now however only be true or false we can 
express all possible options between two boolean value) s, B1, B2 (say) 
in a simple table. 

The operators used are: 


(a) BL A B2 
The “basic symbol> A stands for ‘and’ and indicates the conjunction 
of B1, B2. Thus te A false is false 
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(b) BB 
The symbol ~] stands for ‘not’, meaning the negation of B, thus 
“|true is false, and }false is true 

(c) B1 V B2 
Here, V stands for ‘or’ meaning the disjuction of B1, B2, so that 
true V false is true 


(d) B1 D B2. 
Here, > stands for ‘implies’, the implication symbol, so true > false 
is false. 

(e) Bl= B2 
The symbol = stands for equivalence, reading as ‘is equivalent to’. 


Thus false = true is clearly false. 


The table expressing all possible combinations follows: 


Bl false false true true 
B2 false true false true 

“| Bl true true false false 
BIA B2 false false false true 
B1 V B2 false true true true 
Bi > B2 true true false true 
Bl = B2 true false false true 


6.2 Declarations 
We have formally, 
<boolean type declaration» ::= boolean type) (type list? (6.2) 
where 
boolean type) ::= boolean | own boolean 


and where (type list) (2.19) and own (section 3.5) are previously 
explained. 


(boolean array declaration) ::= (boolean type) array array list) (6.3) 
The (array list) is the same as that in (2.21, 22, 23, 24, 25). Thus 


boolean arrays have the same formal appearance as arithmetic arrays, 
with the exception of the prefix boolean, and the fact that they cannot 
appear in arithmetic expression)s. 


6.3 Simple boolean expressions 


The basic elements, or (primary? are defined as, 
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<boolean primary» ::= “boolean value) | (variable) | 
“boolean type procedure call) | <relation> | 


( boolean expression) ) (6.4) 


The structure of the “simple boolean expression) is defined in the 

following hierarchical manner, with each “boolean operator? defined in 

its order of precedence. The situation is not quite as with (arithmetic 

expression) s, as each ( boolean operator) has a different precedence. 
Firstly, 


boolean secondary) ::= boolean primary? | 
7] “boolean primary) (6.5) 
Example 1 OK “True ODD “| (M +2)x2=M 


The RH ¢relation> in this is only true if M is even. 
Next we have the 


“boolean factor) ::= boolean secondary > | 
<boolean factor) A boolean secondary) (6.6) 
Example 2 ~|x<y “k<yAxAZ2A ODD 
“boolean term) ::= (boolean factor> | 


<boolean term> V boolean factor» (6.7) 
Example 3 x<y Vx=1l0V 7] b 


That is, x< y orx= lor not b. 
Finally, 


<implication> ::= boolean term) | 


<implication) > (boolean term) (6.8) 


The precedence rules, i.e., order of evaluation of a <simple boolean 
expression) are clearly therefore: (a) any Carithmetic expressions, 
(b) any <relation?s (c) any negations, (d) any conjunctions, (e) any 
disjunctions, (f) implications, (g) equivalences. This last named occurs 
formally as 

<simple boolean? ::= implication? | 


<simple boolean) = Cimplication> (6.9) 


Example 4 x<y+3 Ap ¥O0A ODD V (tne = | OK) 


The usual expansion of 6.9 to include a conditional form takes the name: 
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“conditional boolean expression) ::= Cif clause) 
<simple boolean) else 


“boolean expression) (6.10) 


So that we have finally, 


(boolean expression) ::= simple boolean> | 


«conditional boolean expression> (6.11) 
Examples ifa<bAc+d#ékt2Vv |b=3 thenx<y else x>y 


Exompleé Use of (boolean expression) in an (arithmetic expression): 


K := K+ (if x<yAt#3 then S else 
if a>bV  |OK then S+ 1 else S+ 3); 


Exomple7 Use of “boolean expression) in a <statement> 


if x<y A (if ]OK then r<s else r>s) then S :- S$: T 
else S := $+ T-K; 


Exomple8 The (conditional boolean expression) allows a concise inter- 
pretation of the “boolean operator )s, for 
“]A_— means’ if A then false else true 
AAB means if A then B else false 
AVB means if A then true else B 
A >B means if A then B else true 
A=B means if A then B else |B 


6.4 Boolean statements 


The syntax of these in no way differs from that earlier defined in chapter 
3, except that of course the (left part>s must all be declared as boolean 
(variable) s as in 6.2. 


Example9 An integer array (a) holds a number of odd and even integers. 
To scan this array, storing the odd components in a separate 
array (b), and accumulate their sum, and similarly for the even 
components, storing them in array (c). The following piece of 
«program illustrates at least one method: 
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begin integer array a[1:p], b[1: ql], c{1:p-q]; 
comment the exact values of p, q would need to be fixed earlier; 
boolean OK, ODD; integer i, e, odds, evens, j, k; 
i t= j := 1; odds := evens := 0; 
fori := 1 step 1 until n do 
begin comment now to scan each element; 
e := ali]; comment this speeds up repeated references to a; 
ODD := (e+ 2)x2=e; OK := e< 152; 


comment note the simple manner of assigning these boolean 
variables. We want to exit if any of a[i] are found to exceed the 
value 152; 


if ODD then 
begin if OK then 
begin b([j] := e; j:= j+ 1; odds := odds +e end 
else to go OUT; 
comment j is the subscript pointer to the next empty element of b 
end else if OK then 
begin c[k] := e; k := k+1; evens := evens+e end 
end i loop scan; 


OUT : comment alternative action not defined further; 


oe 8 © © © © © © © 6 ee ee ee 


6.5 Application 


Example 10 Asa final example in this section we return to give a more 
natural expression of example 8 in chapter 4. Again the input— 
output parts are referred to chapter 8 in particular. 

begin integer i, j, n;  inreal (1, n); 

begin integer array a[l:n,1:n]; 
for i : = 1 step 1 until n do 
for j := 1 step 1 until n do 
begin if i= j AN ifn then ali, i] :=1 else 
if i>jVje=n then ali,j] := -DtG+j-DN else 
if i<jAj#on then ali, j] := 0 
end; 
outarray (2, a); 
end 


end: 
59 
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6.6 Expressions 


With the (boolean expression) we have now completed the description 


of the formal types of expression which can occur, and we can formally 
define 


{expression) ::= arithmetic expression> | 
€boolean expression> | 


<designational expression> (6.12) 
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Procedures 


Where a “statement > or “block> is entered and re-entered continuously 
by a “program >, or perhaps perfoms a useful algorithm which could be 
used in other <program?s, it is possible to characterize its definition by 
a method other than by using < label) s and “goto statement?s. The spec- 
ific formalism used to handle such description is called the 
PROCEDURE. The algorithm is described by a (procedure declaration >, 
anticipated in (3.12), and the (statement) which forms the ‘procedure 
body) is then automatically entered and executed following a CALL of 
the procedure via a (procedure statement >, control then returning to the 
point of call. 


Exomple 1 An application requires computation of an arithmetic 
expression) with a non-standard function, cosh(x). We wish to 
calculate 


yo X cosh 3x _ sin (x cosh 12)/cosh (log.(x)’”) 


begin real x, y, chi, ch2, ch3, ch4; 


inreal (1, x); comment this inputs the initial value of x; 


begin real ch, z; z:= 3.0x x; 


begin real e; e := exp(z); 
ch := .Sx (e+ l/e) 
end; chi := ch 


end; 
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real ch, z; 


real e; e := exp(z); 
ch := .5x (e+ 1/e) 
ch2 := ch 


real ch, z; z := 12.0; 
real e; e := exp(z); 
ch := .5x (e+ 1l/e) 
ch3 := ch 


real ch, z;  z := In(x) ft 1.5; 
begin real e; e := exp(z); 
ch := .5x (e+ le) 


ch4 := ch 


Various solutions to this example are obviously possible, but the 
above exhibits some specific features. The program segments enclosed 
in the outlines do essentially the same thing, forming the cosh function 
in an efficient manner. In this context it is worth observing that 


(a) the argument z (of coshz) is evaluated once and for all in the 
outer “block? of each segment outlined. That is, a numerical 
value of the argument expression is assigned to z. 


(b) the inner (block) of each outlined segment is virtually self-con- 
tained. The argument value, once assigned in the outer <block> is 
all that is subsequently needed, with the exception of a global 
(variable ) which can be assigned the value of ‘coshz’. Even this 


could be done in the outer “block >, leaving the inner absolutely 
self-contained. 


The notation used in this example illustrates the need for a special 
syntax for handling such series of ‘almost identical’ (statements or 
€block>s which are virtually self-contained. 

The handling of such problems is often described by the term ‘subrou- 
tine’; that is, a piece of program which is frequently entered, albeit with 
different input-output values. In many machine-code languages, special 
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conventions exist, where, in the absence of names for variable addresses, 
as in the higher level languages, the input—output values (or 
PARAMETERS as they are called) are to be found in (say) the first few 
locations occupied by the subroutine itself. Its ‘front end’ is a kind of 
posting box. These general purpose, or ‘utility’ programs are usually 
available from a library of such programs and cover special purpose or 
numerical computations involving a degree of knowledge of numerical 
analysis not normally necessary to simply use them. One arranges to 
copy the body of the subroutine into the computer, incorporated with the 
main user-written program in such a way that a CALL on the subroutine 
will involve: 


(a) A link-jump to the subroutine, placing in its first location the 
address of the instruction causing the jump. This enables the sub- 
routine to know its point of return. 


(b) The link-jump instruction will usually also involve placing the 
addresses of the operands in the subroutine (the relative addresses 
of the operands) in some standard manner. 


(c) Execution of the body of the subroutine, placing results in pre- 
assigned locations and return to main program, at the instruction 
following the original jump. 


In Algol all this is provided automatically in a generalized subroutine 
concept called the PROCEDURE. The areas boxed in the above example 
will be shown to be equivalent to calls of the same procedure, the body 
of which is substantially the innerblock ‘begin real e;....... > shown. The 
outer-block ‘begin real z;.....” is essentially the means for passing the 
values (and as we shall see, also the names) of the parameters. Thus ‘z 
is simply a special kind of input-parameter, and ‘chl, ch4’ are (global) 
output parameters. 


? 


Two kinds of procedure are distinguished formally, 


<procedure declaration) ::= (simple procedure) | 


<parameter procedure) (7.1) 


and their activations are described by 


<procedure statement) ::= (simple procedure statement) | 
<parameter procedure statement) (7.2) 


correspondingly. 
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7.1 Simple procedures 


This is just a parameterless construct, with mainly global <variable)s, 
described formally as, 


<simple procedure) ::= simple non-type procedure? | 

<simple type procedure> (7.3) 

where the 

<simple non-type procedure ::= procedure “procedure identifier > 
€procedure body? (7.4) 
and 

Cprocedure identifier> ::= identifier) (7.5) 
«procedure body» ::= statement) | <code> (7.6) 


Observe from (3.9) that a «procedure body) might be (and usually is) a 
<block)> , as a result of (7.6). 


Example 2 procedure cosh; y := (exp(x) + exp (— x) )/2.0; 


Example 3 procedure cosh; 


begin real E; E := exp(x); y := (E+ 1.0/E)x .5 end 
The “procedure identifier) can be used to store a value also, and not 
just the name of the procedure, so we define 
«simple type procedure» ::= procedure type> 
«simple non-type procedure) (7.7) 


where the 


(procedure type> ::= real | integer | boolean (7.8) 


It is useful to point out in this context that in (3.3) we expressly allowed 
assignments to be made to the procedure identifier? which otherwise 
obeys the laws for <identifier> s.* This presents some alternative and 
more compact versions of examples 2, 3 above. 


Example 4 real procedure cosh; cosh := (exp (x) + exp (— x))/2.0; 


This is the same in effect as example 1. 


Exomple 5 real procedure cosh; 


begin real E; E := exp(x); cosh := (E+ 1.0/E)x .5 end 
* ier eee & 
However, it is important to point out that a <procedure identifier> must not 
appear on the RHS of an <assignment statement> unless a recursive 
activation (See 7.3.2) is intended. In this event the <actual parameter part>, 
if any, must be included. 
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7.1.1 Simple procedure calls 
Any of the above parameterless procedures can be activated, or CALLED 
by simply writing its name in an appropriate context. Thus 


<simple procedure statement) ::= (procedure identifier) (7.9) 


Of course there has to be a “simple procedure) declared to correspond 
to such a call. The mechanics of such an activation, which is implicit in 
any call, is to cause a jump to the “procedure body >, its execution and 
an automatic retum to the <statement> or part of «expression ) immedi- 
ately following the occurrence of the procedure name causing the acti- 
vation. A <simple type procedure > can be either called in an 
«expression >, where it occurs as a (primary? or it may stand alone, as 
a “simple procedure statement >. Note also, from (3.12), that a pro- 
cedure declaration) may occur anywhere in the (declaration part), 


(3.17). 


Example 6 (i) A call of example 2 could take the form 
x:= 5; cosh; outreal (2, y); 
(ii) A call of examples 4, 5 might be of the form 


x t= 5; outreal (2, cosh); 


Example 7 We can now show the advantages of this notation by reprogram- 
ming example 1, dispensing with the switch and various jumps. 


begin real x, xl, chl, ch2, ch3, ch4; 
real procedure cosh; 
begin real E; E := exp(x); cosh := (E+ 1.0/E)x .5_ end; 


inreal (1, xl); x := x1; chl := cosh; 
x := 3.0 «xl; ch2 := cosh; 

x := 12.0; ch3 := cosh; 

x i= In(xl) 7.1.5; ch4 := cosh; 

y := xl/chl x ch2 - sin(xl x ch3)/ch4; 


il 


Clearly a more compact result. If the reader studies example 7 and 
example 1 closely, in conjunction with the remarks in 7.1.1, he will see 
the precise mechanism of procedure call, which is quite general, and not 
restricted to <simple procedure)s of the above variety. 


Example 8 A procedure and call to solve the quadratic ax? + bx +c=0 
for real roots only. We give this as a self contained <program>. 
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begin real a, b, c, xl, x2; 
procedure quadratic; 
begin real d; d:=b t2-4xaxc; 
if d<0 then go to FAIL else d := sqrt (d); 
xl := (b+ d)/(2.0x a); x2 := (b- d)/(2.0 x a); 
go to OUT; 
FAIL : output 0(2, ‘COMPLEX ROOTS’); 
OUT : 
end; 
comment now comes the main <program), or driving part; 
L: input 3(1, ‘’, a, b, c); 
quadratic; output 2(2, ‘’, x1, x2); 
go to L 


end; 


7.2 The parameter procedure 


The main difference between the « parameter procedure) and the “simple 
procedure) just described, is that the former has its exchange variable)s 
explicity displayed as PARAMETERS. 

Two kinds of such procedure, corresponding to the type and non-type 
forms of (simple procedure are also allowed. 


<parameter procedure) :t= (non-type parameter procedure) | 
«type parameter procedure) (7.10) 
where the 
(non-type parameter procedure) ::= procedure 


(procedure heading» 
{procedure body» (7.1) 


and 


<type parameter procedure ::= procedure type) 

<non-type parameter procedure) (7.12) 
However the principal difference between (7.4) and (7.11) lies in the 
elaboration of the (procedure heading >, which replaces the simple 


«procedure identifier) type of heading of 7.1. 
This is given by 
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<procedure heading) ::= “procedure identifier) 
<formal parameter part) ; 


<value part) specification part) (7.13) 


and where 


<formal parameter part) ::= («formal parameter list) ) (7.14) 


The function of the <formal parameter list) is to display the list of 
those <variable)s (of the (procedure body) ) which act as input—output, 
or global—local exchange parameters. Thus 


«formal parameter list) ::= (formal parameter) | 
<formal parameter list) 
<parameter delimiter) 
«formal parameter> (7.15) 


The <parameter delimiter) is usually a simple comma, but provision is 
also made for further commentary material designed to show the meaning 
of each ¢ formal parameter), if required. Thus 


parameter delimiter) ::= ,| ) (letter string) : ( (7.16) 
and where 
(letter string) ::= (letter) | “letter string> (letter) 


Example 9 procedure QUADRATIC (a, b, c) are the coefficients and the 
roots are: (xl, x2); 


This is a (non-type parameter procedure >, with (in the obvious context 
of example 8), a, b, c as input parameters, and xl, x2 as output para- 
meters. Thus a, b, c, xl, x2 are all (formal parameter)s. The above part 
of a procedure is undefined syntactically, but given in this way merely to 
show the form. It is equivalent to procedure QUADRATIC (a, b, c, xl, x2); 
Observe also that the ORDER of the ¢formal parameter)s in the 
<formal parameter list) is quite immaterial, except that any call must 
match the order defined in the <parameter procedure). 
Continuing with the definitions, from (7.15), we have 


“formal parameter) ::= identifier» (7.17) 


The clear advantage of this notation is that the (procedure body can 
now be made into a self-contained (block), with all extemal commun- 
ication via a set of formal parameter variables, which will be replaced at 


a call by the actual program “variables. This we shall elaborate in 
7.2.2.1. 
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The definitions in (7.13) are not yet complete, as the “specification 
part) and (value part) remain to be formally identified. 
7.2.1 Specifications 
Although it is not obligatory to write a specification of the (formal para- 
meter)s, many Algol 60 compilers do actually require it. Subset Algol 
(chapter 10) demands it. The inclusion of a specification will usually 
facilitate efficiency in compiled code, since the compiler is then able to 
anticipate the nature of expected (actual parameter) s. We have formally 
{specification part) ::= empty) | <specifier) identifier list); | 
(specification part) specifier) 
(identifier list) ; (7.18) 
There may thus be no specification at all, or a list of some or all of the 
< formal parameters, prefixed by a <specifier) which indicates the type. 
In the usual way we shall have 
(identifier list) ::= (identifier) | “identifier list), identifier) (7.19) 
The permitted types of (formal parameter) are formally given as: 
<specifier) ::= string | real | integer | boolean | 
array | rea! array | integer array | 
boolean array | label | switch | procedure | 
real procedure | integer procedure | 
boolean procedure (7.20) 
The reader will observe that every type of (variable) is represented 
here, and we shall deal with the specific actual replacements in the rest 
of this chapter. It is usually essential that the (actual parameter) which 
occurs in the <parameter procedure statement ) corresponds in type with 
its formal counterpart. 
7.2.2 The parameter procedure statement 


This is very similar to the (simple procedure statement >, except that 
provision has now to be made for the substitution for the (formal para- 
meter)s by the (actual parameter )s. Otherwise the occurrence in 
<expression)s or as stand-alone (statement)s is identical to 7.9. 
Formally, 
(parameter procedure statement) ::: (procedure identifier) 
<actual parameter part)(7.21) 


Moreover, 
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(actual parameter part> ::= (<actual parameter list >) (7.22) 
and 


«actual parameter list) ::= actual parameter) | 

Cactual parameter list) 

<parameter delimiter) 

(actual parameter) (7.23) 
We referred to the form < parameter delimiter» in (7.16), although it is 
neither obligatory in the call, nor need occur in the same fom. This is 
perhaps an obvious conclusion from the fact that <letter string) has no 
formal semantics. 


Before giving examples it is necessary to consider the forms possible 
for the (actual parameter>. 


7.2.2.1 The actual parameter 
The forms allowed are 


Cactual parameter) ::= expression) | (array identifier) | 
«procedure identifier > | 
«switch identifier) | (string) (7.24) 


The strict actual-formal correspondence is given in the following table. 


«formal parameter > Cactual parameter > 
rea} 
“arithmetic expression) 
integer 
boolean “boolean expression) 
array 


real arra 
m Carray identifier) 
integer array 


boolean array 


label <designational expression) 
switch «switch identifier> 
procedure 


real procedure ; oF 
. «procedure identifier) 
integer procedure 


boolean procedure 
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In qualification, we should say that the “array identifier > occuring as an 
actual replacement at the call, must be declared of the same type, e.g., 
arithmetic or boolean, in the calling <block>. The same applies to the 

¢ procedure identifier), of course. It would make little sense to try and 
get a boolean array parameter as the output of a procedure delivering a 
real formal array result. 

In all cases the (actual parameter > must be used in the same formal 
context as its formal counterpart; that is, even though the correct types 
of parameter are used, it is still incumbent on the programmer to ensure 
they make correct <statement?s, when the (actual parameters replace 
their formal counterparts in the «procedure body>. We shall shortly 
elaborate this, but it is clear that an output formal parameter (such as xl, 
x2 in example 9) could not be replaced by an (arithmetic expression) as 
an (actual parameter). This would make a (statement) with an 
«arithmetic expression) on the left hand side, which is formally 
prohibited. 


7.2.2.2 Procedure equivalence blocks 

The operation and interaction of procedure calls and the corresponding 
procedure declaration is best understood using an extension of the 
‘equivalence’ programs of chapter 5. In particular, in sections 5.2 and 5.3 
we were able to give a piece of program, using more fundamental Algol, 
which exactly describes the operation of the higher-level <for statement) 
construction. The point was made in example 1 of chapter 5 that many 
such redundant constructions are available in Algol 60. Redundant in the 
sense that the operation of the particular construction can be wholly 
expressed in terms of ‘simpler’ Algol 60. The constructions for which this 
is true are (for statements, boolean expression) s and procedures, all 
of which can be perfectly well defined in basic Algol 60. 

The idea of a basic Algol 60, or the CANONICAL FORM of any 
Program is discussed in chapter 7 (section 4) when the processing of an 
Algol 60 program to an irreducible form is described. This terminology is 
not appropriate here, for “arithmetic expression) s are not in this same 
canonical, although they serve as an intermediate stage in the processing 
(or rewriting) of, say, a (for statement > in non for-statement terms. 

The operation of a procedure call is given formally in the Report as 
‘Finally the (procedure body> ... is inserted in place of the «procedure 
statement), and executed’. That is, the body, whether a <block D or 
simply a <statement> is regarded as substituted in the program at the 
point of call, together with whatever modifications are necessary to make 
it a valid substitution. The ‘modifications’ are the processes by which the 
< actual parameter)s substitute their formal counterparts. This is to be 
understood by a VIRTUAL BLOCK encompassing the actual procedure body. 
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This virtual block only appears explicitly when we transform, or elabor- 
ate the procedure call into its equivalent, non-procedure form. Moreover 
a virtual block will only appear in the elaborated procedure call if 


(a) at least one of the (formal parameter)s are specified by value 
(see 7.23 below) 

(b) if it is a type procedure, i.e., one in which a (procedure type> is 
used. (compare (7.8)). 


For example, the declarations and call 


begin real procedure cosh(x); real x; 
begin real e; e := exp(x); 
cosh := .5~x (e+ 1/e) 
end; 
real result; 


call : result := cosh(3.28); 


is formally equivalent to 


begin real result; 

call : begin real cosh; 
begin real e; e := exp(3.28); 
cosh := .5x (e+ 1l/e) 
end elaborated body of ‘cosh’; 
result := cosh 


end elaborated virtual ¢block? of ‘cosh’; 


o 8 © © © © eee 


The outer (block> ‘begin real cosh;’ is the virtual block while the inner 
‘begin real e; ...’ is the <procedure body> proper. The exchange between 
the global program variables and the procedure name is performed after 
exit from the (procedure body» immediately prior to exit from the virtual 
block. 


7.2.3 Call by name or value 

Before citing examples of (actual parameter )s, it is necessary to undet- 
stand the action of the actual-formal substitution in detail. When an 

€ actual parameter» occurs in a “procedure statement >, it is understood 
as replacing its formal counterpart, provided always that their types match 
exactly according to 7.2.2.1. 
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The action of the procedure call must be understood in the following 
stages: 


(a) The “procedure body» is copied into the exact (statement ) where 
it is called. 


(b) Apart from the <variable)s local to the (block) of the «procedure 
body), all «formal parameter)s throughout the (procedure body? 
are replaced by their actual counterparts (name replacement). 


(c) Any “formal parameter)s included in the <value part) of the 
« procedure heading>, are evaluated BEFORE entry into the 
€procedure body», and execution thereof. This effect can best be 
described by the creation of a virtual < block), in which the value 
parameters are evaluated. This virtual <block> is a level immedi- 
ately outside the (block ) of the body. 


(d) The “procedure body? is executed, control returning to the 
« program) at a point immediately after the call. 


The form of value specification is 


<value part) ::= <empty) | value identifier list? (7.25) 


We can now illustrate further the introductory comments in section 
7.2.2.2 on equivalence blocks. In formally elaborating a procedure call: 


(a) the virtual block is written if it is in a type procedure, or if at 
least one parameter is specified in the Cvalue part); 


(b) the virtual declarations include the name of the procedure, if it is 
a type procedure, and the names of all value variables; 


(c) the value variables are assigned their (actual parameter) values, 
in the virtual block; 


(d) the procedure body is elaborated, with all ¢ formal parameter) 


variables replaced by the names (or expressions) of their actual 
Parameter counterparts. 


Although the elaboration mechanism is used extensively, we give the 
following example of its use. 


Exomple 10 We can now rewrite example 1 in procedure form, in a manner 


which formally is equivalent to the non-procedure form of 
that version. That is, if the following procedure calls are 
formally elaborated according to the rules of the procedure 
syntax, example 1 results exactly 
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begin real x, y, chl, ch2, ch3, ch4; 
procedure cosh (z, ch); value z; real z, ch; 
begin real e; e := exp(z); 
ch := .5~x (e+ 1/e) 
end; 


inreal (1, x); 


| cosh (In(x) f 1.5, ch4); 


y := xx chl/ch2 - sin(x x ch3)/ch4; 


ee © © © © © © © ew ee 


Comparing example 1 with example 10, we observe that the areas out- 
lined are formally equivalent, that is by processing the above text with 
its calls on ‘cosh’, according to the rules (a), (b), (c) and (d) above, 
example 1 is produced. Clearly the above is more compact. The rules 
concerning ‘value parameters’, i.e., (formal parameter)s specified in 
the <value part> are clearly illustrated by the outer block of example 1, 
‘begin real z; ... ’ — that is the ‘virtual (block>’ referred to in (c). The 
€variable) s in this outer, or virtual <block> in example 1 are the 
elaborated <formal parameter)s of example 10. Specifically, any of these 
given in the <value part) (‘z’, for example) are assigned their values 
(initialized) in this virtual (block) before entry into the procedure body 
proper, i.e., ‘begin real e; ... ’. The single ‘name’ parameter, i.e., ‘ch’ in 
‘procedure cosh’ is used as an output variable and can have a numerical 
value assigned to it in the procedure body. Any actual parameter) such 
as chl, ch2, etc., can then have this value transferred to it by name. 
This will be understood by studying carefully the boxed-in sections in 
example 1 and 10 which are identical in function. 

We shall further illustrate this vital point, which essentially dis- 
tinguishes Algol from other languages and makes it very powerful. 


Example 11 Consider the following example to evaluate a fourth order 
polynomial, and evaluate it for several arguments. 


The polynomial is y = ~ nx + x*~ 2x? + 8x4 n being some 
constant. 
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begin procedure POLY4 (x, y); real x, y; 


yi=—onxxtx f2-2.0x x *3+8.0x x t 4; 
comment this “procedure body) has only one <statement>; 
for t := —5S step 1 until 5 do 


begin outreal (2, w) end; 
comment the assumption is that both t, w are global to the 
<block) ; 

end 


ee © © eee 


The formal elaboration of this procedure call would give 
begin for t := - 5 step 1 until 5 do 
wis —-nx(t {2+ sin(t))+(t ft 2+ sin(t)) ft 2 
~2.0x (t 12+ sin(t)) f 3 
+8.0x (t f 2+ sin(t)) ft 4; 


begin 


outreal (z, w) 
end; 
comment we are assuming that t, w are global variables 


ed 


Note the correspondence formally of the outlined sections in the 
original and elaborated pieces of (program). 

Otherwise the two above (bhlock)s are identical. This example illus- 
trates clearly the advantage of calling ‘by value’ wherever possible. In 
In the procedure ‘POLY4’ we put in a specification that x, y are of type 
real; this is optional, but probably good practice since it illustrates 
clearly the nature of the <formal parameter)s. But the non-specification 
of ‘x’ by value means that the (arithmetic expression) ‘t f 2+ sin(t)’. 
will get copied in place of x in the body of POLY4 when execution takes 
place. The elaboration shows clearly that this <expression) then gets 
evaluated 4 times instead of 1, which is all that is necessary. Clearly 
this is grossly inefficient, for ‘t f 2+ sin(t)’ involves 2 accesses of ‘t’ 
and a sine subroutine evaluation. There may be cases where this 
repetition of an expression? is desirable; for example, when one wishes 
to modify a general (expression), i.e., evaluate it for different arguments, 
within the (procedure body). However, in this example, it would be 
better to rewrite the (parameter procedure) as 
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procedure POLY4 (x, y); value x; real x, y; 
yi=onxx+xf 2-2.0x xf 3+8.0«x f 4; 
The formal elaboration of the <for statement is then: 


begin for t := - 5 step 1 until 5 do 
begin 


begin real x; x :=t f 2+ sin(t); 
wii=—-nxx+xf2-2.0xx{ 3+80x xf 4; 
end elaborated virtual <block> of ‘POLY4’; 


Ce 


Here one can see explicitly the formal mechanism which follows a speci- 
fication by value. All «formal parameter)s so specified are evaluated in 
a virtual «block > immediately prior to entry into the main block > of the 
« procedure body). Thus repetitive evaluations are avoided. 

To see how this affects particular parameters we will now consider in 
detail the application to different situations. 
7.2.4 Expression parameters 


The arithmetic expression) was used to illustrate the call-by-name 
concept in 7.2.3, as it is perhaps the most common. An example where the 
name concept is particularly useful is as follows. 


Exampte 12 To evaluate the mean of any given function, e.g., f(x) at two 
arbitrary points x = a, x= b. 


This can be written as a (type parameter procedure): 
real procedure mean (f, x, a, b); value a,b; real f, x, a, b, 
begin real d; x := a; d:=f; 
x i= b; mean := (d+ f)x .5 
end; 
We shall now give a <block) which calls this procedure: 
call: begin real y; integer k; inreal (1, k); 
y := mean (sin(y)x In(y), y,- 5x k, 3.8); 
outreal (2, y) 
end; 
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The mechanism of ‘mean’ will now become clear as we elaborate its call 
into canonical form. We call ‘f’ and ‘x’ the name parameters, since we 
require to modify both in the <procedure body). ‘a’ and ‘b’ on the the 
other hand are essentially input values only, and they are accordingly 
specified by value. In the usual mathematical sense, it is essential to 
realize that ‘f’ is a function of ‘x’. The elaboration gives 


call: begin real y; integer k; inreal (1, k); 


a:= -5xk; 


begin real mean, a, b; 
begin real d; 

y i= a; d= sin (y)x In(y); 

y := b; mean := (d+ sin(y) x In(y)x .5 


end elaborated body of ‘mean’; 


y i= mean 


end elaborated virtual block of ‘mean’; 


outreal (2, y) 
end 


Again the boxed in segments of the original and elaborated form of the 
procedure call ‘mean’ correspond exactly. 

Perhaps the greatest advantage of this call-by-name is the generality 
which can be accorded to ‘f’. Such a procedure could become part of a 
library of procedures designed for general purpose use, although this par- 
ticular example is a very trivial illustration. 


Exomple 13. -A procedure to sum the general finite series given by 


q 
=”; = We + Wey tt Wyyg teens Wy 
=p 


Here the general term of the series, w, is a function of 1, which acts like 
an independent <variable> and must be included in the (formal parameter 
list). We can express it as 


real procedure SUM (w, i, p, q); value p,q; integer p,q, i; real w; 


begin real s; s := 0.0; 
fori := p step 1 until qdo s :=stw; 
SUM :=s 

end; 
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100 
Example 14 To sum the series »: (7 + 1) sin (3/), using example 13 
J=O0 
above. 


here : begin real answer, integer j; 


answer := SUM ((j t 2+ 1)x sin (3 x j), j, 0, 100); 


outreal (2, answer) 


end here; 


Again, to understand the precise mechanism of the procedure call, we 
shall formally elaborate this: 


here : begin real answer; integer j; 


begin real SUM; integer p,q; p: 


begin real s; s := 0.0; 


0; q := 100; 


for j := p step l until qdos :=3+ (Gj t 2+ 1)x sin(3 x j) 
SUM := s 

end elaborated body of SUM; 

answer := SUM 

end elaborated virtual <block) of SUM; 


outreal (2, answer) 


end here; 


Note once again how the outlined sections in the original and elaborated 
program versions formally correspond. 

This <block> is then formally equivalent to the form above, using an 
explicit call of ‘SUM’. 


7.2.4.1 Function parameters 

In example 14, above, the (actual parameter) ‘(j f 2+ 1)x sin (3x j)’ 
is an example of a parameter which contains a standard function. It 
clearly must be possible to include user-defined functions — as pro- 
cedures — as well. Often this can lead to greater flexibility. 


Example 15 Rewrite example 14 using a <parameter procedure) definition 
of the general series term. 
We could rewrite ‘here’ as follows: 


77 


ALGOL 60 PROGRAMMING 


here : begin real answer; integer j; 
real procedure f(i); value i; integer i; 
f:= Gi $}2+1)x sin (3~x i); 
outreal (2, answer); 
end; 


For completeness we shall give the elaboration of this (statement) as 
follows, in two stages, 


here : begin real answer; integer j; 
real procedure f(i); value i; integer i; 


f := (i t 2+ 1)x sin (3 x i); 


begin real SUM; integer p,q; p: 100; 


begin real s; s := 0.0; 


for j := p step 1 until q do s := s+ f(j); 
SUM :=s 

end elaborated body of SUM; 

answer := SUM 

end elaborated virtual (block> of SUM; 


outreal (2, answer) 

end 
But we must still elaborate the call of ‘f’ in the <for statement> of 
‘SUM’. This gives an identical result to the formal elaboration in example 
14, as the reader may verify. At each formal elaboration of a procedure 
call we remove the «procedure declaration) so elaborated, gradually 
reducing the text to canonical form not including any procedures. This 
technique has already been used to reduce, or simplify the (for state- 
ment> constructs earlier. 


Example 16 To sum a convergent infinite series. We shall give a pro- 
cedure to compute the sum 
oO 
YW; = Wy t Wy +t We + oe 
t=0 
It is assumed that the series is convergent, so that 


lim w, = 0 


i 00 
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To get a result within a prescribed accuracy, we will need to continue 
summing for so long as w, > eps, where eps is the prescribed tolerance. 
For example, if eps = .5x ,,.~ 8 the sum to infinity will be accurate to 8 
decimal places. 


real procedure infseries (term, i, eps); value eps; 


real eps, term; integer i; 

begin real s; s := 0; 
for i := 0, i+ 1 while abs(term)> eps do s := s+ term; 
infseries :=s 


end infseries; 


It is worth observing here that although this is designed for clarity, the 
double occurrence of the <variable> ‘term’ is both unnecessary and 
inefficient. Name-parameters like ‘term’ are, in effect, equivalent to pro- 
cedure calls, as we shall describe in 7.2.7. An alternative, more efficient 
version is 


real procedure infseries (term, i, eps); value eps; 


real eps, term; integer i; 

begin real u, s;_ s := 0.0; 
i:= 0; u := tem; 
for i := 1, i+ 1 while abs(u)> eps do 
begin s = S+u; u := tem end; 
infseries := s 

end; 


The number of references to ‘term’ inside the for-loop is now one. 


Emmple 17 To sum two series, using example 16: 


oo mot 
(a) rhe-ceee Ss < jes Ge geod hak 
Ly i? 2? 32 4? 


wal 


(b) To sum the series of chapter 5, example 7, using the same recursive 
2 
term definition, i.e., u,(x) = pa, OY 14,-1(X), Up = 1 etc. 


The result is given as a complete (program) , assuming that ‘infseries’ is 
in a global <block> 
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a: begin integer k, j; real answer; 
real procedure F1(i); value i; integer i; 
begin Fl := if i= 0 then 1 else C1) f (Gi- D/i 12; 
k := k+1; 
end F1; 
comment we have used a global <identifier) ‘k’ to count the 
number of times the procedure ‘Fl’ is entered. This gives the 
number of terms needed to gain a particular accuracy; 
k := 0; answer := infseries (F1(j), j, -5 * 10-8); 
output 2(2, ‘’, answer, k); 
comment k will now be the number of terms needed to get 8 decimal 
place accuracy; 


end a; 


b: begin integer k, j; real x; 

real procedure TERM(i); value i; integer i; 

begin own real oldterm; real u; 
if i= 0 then u := 1.0 else u := -oldtermx x t 2/(2xix(2xi-1)); 
TERM := oldterm := u; k := k+1 

end TERM; input 1(1, ‘’, x); 

k := 0; answer := infseries (TERM (j), j, .5 * io 8); 

output 2(2, ‘’, answer, k); 

end b; 


The method used here is slightly different from that of example 7 in 
chapter 5. In particular note the use of the own variable» ‘oldterm’. 
The value of each tem is thus left in ‘oldterm’ on exit from ‘TERM’, and 
hence is available on the next entry to compute the next term recursively. 
This is a, perhaps rare, example of own variables being of some real use 
(see 3.5). The reader is urged to formally elaborate the <statement> 
‘answer := ...’ taking ‘infseries’ first, and then elaborating ‘TERM’, in 
a similar fashion to example 14, until a ¢block> is obtained with no 
references to procedure calls, i.e., a canonical form. 

An advantage is that the precise number of calls of ‘TERM’ is moni- 
tored by the counter k. An interesting further application would be to test 
how far the result agreed with example 10, for cosh(x); part (b) here 
gives a theoretically identical result. 

Incidentally, it is stressed once again, that this is not suggested 
seriously as a practical method of summing series, though ‘TERM’ is 
probably as good a way as any of DEFINING the general term required by 
more efficient series summing procedures. Some efficient methods are 
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discussed in ref. 17, and indeed an example is given in ref. 1, the 
Revised Report. 


7.2.5 Array parameters 

Only the <identifier> corresponding to an array in the calling ¢ program) 
may appear as an actual parameter>. Since the dimensions of the array 
used in the «procedure body) are nearly always explicit, it is encumbent 
on the user to ensure the actual array has the same. Although the sub- 
script bounds do not have to correspond; they must however at least 
INCLUDE the number of entries in the (procedure body), or a subscript 
overflow condition arises. 


Example 18 A procedure to sum the elements of a vector 


real procedure SUMVEC (a, n); value n; integer n; array a; 


comment inclusion of the (optional) specifications helps to 
understand the parameter functions; 


begin integer i; real s; s := 0.0; 
for i:= 1 step 1 until n do s := s+ a[i]; 
SUMVEC := s 


end SUMVEC; 
comment now to drive ‘SUMVEC’ through an example (block); 
begin array b(0: 20]; inarray (1, b); 


comment this fills ‘b’ from the input channel ‘I’ 


answer := SUMVEC (b, 10); | outreal (2, answer); 


Observe that the elaboration of this produces the following equivalent 
«block? : 


begin array b[O0: 20]; inarray (1, b); 
real SUMVEC, 


begin integer n; n: 


begin integer i; real s; s := 0.0; 
for i := 1 step 1 until n do s := s+ b[i]; 
SUMVEC := s 


end elaborated body of ‘SUMVEC’; 

answer :- SUMVEC 

end elaborated virtual <block) of ‘SUMVEC’; 
outreal (2, answer); 


SY 
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It is clear from the elaboration that only elements b[1] to b[10] are 
summed, and output. Elements b [0] and b[11] to b [20] are not used. 
If the intention was to sum the lot, then the bounds on the subscripts 
must formally coincide with those of ‘SUMVEC’. One could thus write: 


begin array b[1: 21]; inarray (1, b); answer := SUMVEC (b, 21); 


outreal (2, answer); ........ eee eee 


The great flexibility of the notation in Algo! will be noted. It is, however, 
a good habit to keep the actual array bounds identical to those of the 
formal parameter equivalent. It sometimes happens in practice that 
several different procedures, with different array bounds, have to be used 
in conjunction with one array, and in such cases the above example will 
help to clarify the exact mechanism. 

It is possible, though seldom advisable, to specify an array parameter 
BY VALUE. The same comments as were made previously apply: that is, 
a virtual (block) is created, with virtual <declaration) s of those (formal 
parameter)s which are specified in the <value part>. But an array so 
specified will give rise to a significant increase in storage space at the 
point of entry to the virtual <block>. It may be so large that overflow can 
actually occur, for although this is a virtual mechanism in appearance, 
this is actually what takes place in the implementation of the procedure 
call. 


We can study the exact mechanism by the following example. 


Exomple 19 Illustration of array parameter call-by-value. We give a slight 
variant of example 18, the difference being that ‘SUMVEC’ 
has the array parameter called-by-value. The virtual block 
appearing in the elaborated form of the call of ‘SUMVEC’ 
shows explicitly the very heavy overhead in the implicit 
‘copying’ of the actual array into the formal array. 


begin real procedure SUMVEC (a, n); value a, n; integer n; array a; 


begin integer i; real s; s := 0.0; 
for i := 1 step 1 until n do s := s+al[i]; 
SUMVEC :=s 


end SUMVEC; 
begin array b[0: 20]; inarray (1, b); 


answer := SUMVEC (b, 10); | outreal (2, answer); 


eS 


The formal equivalence-block is the elaborated fom: 
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begin 
begin array b[O: 20]; inarray (1, b); 


integer n, k; real SUMVEC; 


begin array a(0: 20]; 


for k := 0 step 1 until 20 do a({k] := b[k]; 


begin integer i; real s; s := 0.0; 


for i := 1 step 1 until n do s := s+ ali]; 
SUMVEC := s; 

end elaborated body of ‘SUMVEC’; 

answer := SUMVEC 

end elaborated virtual (block? of ‘SUMVEC’; 


outreal (2, answer); 


Points to note here are the formally identical outlined portions, which 
illustrate the value call through the virtual ¢block> of ‘SUMVEC’. In 
this virtual <block> the entire actual array b is copied into array a, ‘k’ 
is an integer variable introduced in the virtual (declaration part) to 
represent explicitly the copying process. A point in favour of this value 
call of array a (as with any value call) is that the actual array b is not 
affected or modified by the procedure call. 


7.2.6 Switch parameters 


This is rather similar to the array parameter, in that only the <switch 
identifier» may appear as an (actual parameter) (7.24). Again, the 
actual bounds on the switch are only apparent from the <procedure 
body, i.e., the context, and the calling <statement ) can only appear in 
a “block> in which an appropriate (switch declaration> is given. An 
example will demonstrate the use. 


Exampic 20 <A piecewise function is defined, such that 
t- sint, t<0O 
f(t) = (1/2 t= 0 
t-cost, t>0 
The arguments ¢ are complicated functions, and a test procedure is to be 
written which will test each function to determine what part of the range, 


and which piecewise element of the dependent function is to be evaluated, 
The resulting values of the f(t) are to be output. 
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procedure TEST (x, which); value x; real x; switch which; 
go to which [if x < 0 then 1 else if x = 0 then 2 else 3]; 
comment another example, incidentally, of a conditional designational 
expression; 
begin switch CASE := L1, L2, L3, T1, T2, T3, T4, out; integer k; real t; 
k := 4; inreal (1, t); 
Tl: TEST (t t 2—:2.0, CASE); 
T2 : TEST (sin(t) x t, CASE); 
T3 : TEST (in(t)+t t 1.5, CASE); 
T4 : TEST (t - 1.0/t, CASE); 
L1:f := t~sin(t); go to final; 
L2:f := .5; go to final; 
L3:f := t - cos(t); 
final : outreal (2,9; k := k+1; goto CASE[k]; 


This saves some space in source text, as the following elaboration indicates 
indicates: 


begin switch CASE := L1, L2, L3, T1, T2, T3, T4, out; integer k; real t; 
k := 4; inreal (1, t); 

T1 : go to CASE [if t + 2- 2.0 <0 then 1 

if t t2- 2.0 = 0 then 2 else 3]; 
T2: go to CASE [if sin(t)x t <0 then 1 

if sin(t)x t =0 then 2 else 3]; 
T3 : go to CASE [if In(t)+t t 1.5 < 0 then 1 else 

if In(t)+t ¢ 1.5 = 0 then 2 else 3]; 
T4: go to CASE [if t- 1.0/t < 0 then 1 else 

if t- 1.0/t = 0 then 2 else 3]; 


else 


else 


L1:f := t~ sin(t); geo to final; 
L2:f:= .5; go to final; 
L3:f := t- cos (t); 
final : outreal (2,9; k := k+.1; go to CASE [k]; 
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This rather contrived example perhaps docs little justice to the switch 
parameter. Its greatest use is in the over-riding of the automatic pro- 
cedure exit retum of control to the <statement) calling the procedure. 
This is at its best when a whole array of (label) s in the calling 
program) are the next destination, as determined by the procedure 
having the appropriate switch parameter. This < switch identifier) carries 
with it the point of return, as defined in the calling <program>, by a 
reference to a specific member of the <switch list). This is very similar 
to assignment to an array parameter. 


7.2.7. Procedure parameters 


The use of the call-by-name mechanism, in conjunction with named par- 
ameters (those not specified in the <value part>), gives sufficient 
flexibility for most purposes. The use, for example, of a function par- 
ameter ‘f’, and its one, or more, independent variables, all as name 
parameters, will facilitate most kinds of generalized procedure. This 
includes series summation, automatic integrators and so on. However 
there are some kinds of generalized function for which this facility is 
inadequate. For example, the definition of a general system of differ- 
ential equations, after reduction to a system of first order, non-linear 
equations (ref. 17), will not be realizable with expression parameters, 
at least, not in the context of a general n-th order algorithm. For such 
cases we have the procedure parameter, as was anticipated in (7.24). 
Indeed, Subset Algol, as we shall consider in chapter 10, does not allow 
the scope of named parameters of full Algo! 60, and the procedure par- 
ameter becomes then the only effective instrument. 

It is worth recalling the simple example 12 (7.2.4) to explain, via the 
usual elaboration, the mechanism of procedure parameters. 


Example 21 Reprogram of example 12 (7.2.4) 
begin real procedure mean (f, a, b); value a, b; real a, b; 
real procedure f; 


comment the <specifier> here was given in (7.20); 
mean := .5 x (f(a) + f£(b)); 
call: begin real procedure SINLOG(z); value z; real z; 
SINLOG := sin(z)x In(z); real y; integer k; 
inreal (1, k); 


y := mean (SINLOG, - 5x k, 3.8); | outreal (2, y) 


oe © © © 2 ew 
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Again, it is better to consider the formal elaboration in two stages, first 
the elaboration of ‘mean’ and then of ‘SINLOG’. 


call: begin real procedure SINLOG(z); value (z); real (z); 
SINLOG := sin(z) x In(x); real y; integer k; 
inreal (1, k); 


a a a ee a 


end elaborated body of ‘mean‘; 


y i= mean 
end elaborated virtual <block> of mean; 


Note the correspondence again of the outlined segments. Finally the 
elaboration of the ‘SINLOG’ calls gives: 


call: begin real y; integer k; inreal (1, k); 


begin real mean, a, b; a := —5xk; b := 3.8; 

begin| begin real SINLOG,z; z:= a; | 
| begin SINLOG := sin (x) x In(z) ones 
mean := SINLOG \ 
| end; 
begin real SINLOG, z; z := b; 
| begin SINLOG := sin(z) x In(z) end; ! 
mean := mean+ SINLOG | 
| end; 
mean := mean x .5; 

end; EO gon oe eer Pane ee 

y <= mean 

end; 


outreal (2, y) 


end 


The dotted outlines again correspond formally in this second elaboration. 
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No further procedure calls require elaboration so these two stages show 
clearly the mechanism of the procedure parameter. 

Clearly the use of procedure parameters does make the text of a pro- 
cedure look more natural. For example, in example 12 we had to set ‘x’ 
(which incidentally we are at liberty to omit completely when the pro- 
cedure parameter is used) before each value of ‘f’ was assigned. Thus 
< procedure body) s will become more compact with this notation. 


Exomple 22 As a matter of interest we give procedure parameter versions 
of examples 13 and 16 of this chapter. 


real procedure SUM(w, p,q); value p,q; integer p, q; 


real procedure w; 


begin real s; integer i; s := 0; 
for i := p step 1 until q do s := s+ w(i); 
SUM :=s 

end SUM; 


comment the series of example 14 could be summed via the following: 


here : begin rea! answer; 

real procedure f(i); value i; integer i; 

f:= G tf 2+1)x sin(3~ i); 

answer := SUM(f, 0, 100); outreal (2, answer) 

end here; 
The formal elaboration of this will of course produce an identical result 
to that of example 14, except that ‘j’ will be formally replaced by ‘i’; in 
fact ‘j’ is deleted entirely in the above. Similarly, the procedure par- 
ameter form of example 16 will be 
real procedure infseries (term, eps); value eps; 


real procedure term; 


begin real u, s; integer i; s := 0.0; u := term(0); 
for i := 1,i+ 1 while abs(u) > eps do 
begin s := s+u; u :=term(i) end; 
infseries := s 


end 


The final two examples we consider in this section are related. In the 
first, a general procedure for finding the roots of a quadratic equation is 
given, and in the second, a general procedure is given for finding 

all roots of a cubic equation, using the quadratic procedure. 
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Exomple 23. The roots of a quadratic equation ax? + bx +c=0 are well 
known as (b + sqrt (b?- 4x ax c))/2a. However they can 
complex depending upon the discriminant b* - 4x ax c. It is 
presumed the reader is familiar with this. 

procedure QUADRATIC (a, b, c, rl, 12, i1, i2); value a, b, c; 

real a, b, c, rl, 12, il, i2; 

begin real discrim; discrim := b t2-4.0x axc; 

if discrim > 0 then 
begin real d; d := sqrt (discrim); 
il := i2 := 0.0; 
rl := (b+ d)/(2.0x a); 12 := (-b-d)/(2.0x a) 
end real roots 
else 
begin rl := 12 := -—b/(2.0 x a); 
il :=-i2 := sqrt (—discrim)/(2.0 x a) 
end complex roots 
end QUADRATIC; 
comment we can incorporate a ‘driver’ <block) here to input coefficients 
and output roots, successively; 
begin real a, b, c, Rl, R2, 11,12; L: input 3(1, ‘’, a, b, c); 
QUADRATIC (a, b, c, RI, R2, 11, 12); 
output 4(2, ‘’, R1, I1, R2, 12); go to L; 

end; 

The (program) here could be stopped by some ‘stop code’ character on the 

input data tape, or data cards, but as such ‘abnormal termination’ takes 


place. There is a facility in chapter 9 (9.6.1.3) which can produce normal 
exit via the procedure call ‘no data’. 


Example 24 In this example we give a (program) to solve the general 
(real coefficient) cubic equation: ax* + bx? + cx-+ d= 0. We 
use the fact, that if r is a known real root (a cubic always has 
at least one real root), then 


ax? + bx? + cx+ d =(x- 1) (ax? + (b+ ar)x - d/r) 


Therefore, if the real root r can be found, the remaining real or com- 
plex roots can be found by solving the factored quadratic, using example 
23. Further, the real root r may be found using the Newton—Raphson 


88 


PROCEDURES 


_ £(,) 

f'(x;) 
Generally the iterative process continues for so long as successive 
approximation to the root, x,, and its improved approximation x, ,,, are 
significantly different. The «procedure declaration> will assume that ‘r’, 
the real root of the cubic, is called with some crude approximation to the 
real root, as might have been obtained by sketching the cubic roughly. 
The Newton—Raphson method is rapidly convergent (see ref. 17) and will 
home on to a solution however approximate the initial information about 
the real root of the cubic; however, it is much more rapidly convergent if 
a good guess is made. 


iterative formula x,,,= x, , for a root of the equation f(x) = 0. 


procedure CUBIC ROOTS (a, b, c, d, r, rl, il, 12, i2, QUAD, eps); 
value a, b, c, d, eps; real a, b, c, d, rl, r2, il, i2, eps; 


procedure QUAD; 


begin comment first we do the Newton—Raphson approximation to the real 
root. It is supposed an approximation is given in ‘r’; real x, y; 
yrau 
again: x t= y; 
yr x— (x « (xx (ax x+ b) +c) + d)/(xx (3.0 x ax x+ 2.0 x b) +c); 
if abs(y - x) = eps x abs (y) then 
go to again else r := y; 
QUAD(a, b+ ax, - d/r, rl, 12, il, i2) 
end CUBIC ROOTS ; 


It is left to the reader to confirm that the Newton—Raphson formula 
actually corresponds to the (statement) immediately after ‘again’. A nest- 
ed form for the polynomial and its derivative has been used, with a gain in 
efficiency (saving in multiplications) already mentioned in example 18 of 
2.6. The iteration termination criterion: abs (y — x) = eps x abs(y) is a 
RELATIVE test, most suitable for floating point computations, particularly 
when y is very large relative to eps. For example, if eps = ,,.- 6, y = yp 
then y + eps = 10°(1+ 10° °). If 10° °is too small (for a given com- 
puter) to measure relative to 1, an ABSOLUTE test will fail. On a com- 
puter where 10° is too small to measure relative to 1, p= 2 maximum. 
Thus the use of a relative test will ensure proper termination, whatever 
the size of the root. 

Consider a (block) which is within the scope of ‘QUADRATIC’ and 
‘CUBIC ROOTS’ above. 
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begin real A, B, C, D, epsilon, r, rl, 12, im1l, im2; 
input 6(1, ‘’, A, B, C, D, epsilon, 1); 
CUBIC ROOTS (A, B,C, D,r,11,im1,12,im2, QUADRATIC, epsilon); 
output 5(2, ‘', r, rl, im1, 12, im2) 


end; 


The reader may elaborate the calls of CUBIC ROOTS and QUADRATIC, 
to verify that the desired result is obtained. 


7.2.8 String parameters 


The concept of a <string> is something of a curiosity in Algol! 60. 
Although they are defined, no facilities are available for their manipu- 
lation, i.e., formation of (assignment statement>s with <string 
variable)s, or indeed even for their declaration. They are only allowed 
to appear in a (program) as a procedure parameter (actual or formal), 
Short of some simple input—output procedures, discussed in chapter 8, 
virtually nothing can be accomplished. A proposal by N. Wirth © for string 
handling, which is undoubtedly one of the best to emerge, is incapable of 
use unless the formal addition of a string declaration is made. With this 
proviso, quite useful string handling is possible by means of code-bodied 
procedures additional to the standard functions. However this goes beyond 
Algol 60, and cannot be our concern here. 

We now give the definitions of (string) which are useful in the context 
of chapter 9. 


(string) ::= ‘ (open string)’ (7.26) 
Copen string» ::= string element > | 
<string element? ‘open string) (7.27) 


That is, a <string> is simply a concatenation of symbols, defined by 
(string element> ::= any symbol other than ‘and’) | <string> (7.28) 


Thus anything is permitted inside the string quotes, the normal Algol 
syntax being completely invalid. We shall have occasion to give a struc- 
ture to a special kind of (string), namely the <format string), in 
chapter 9, the formal appearance of which conditions the output data. 
Example 25* (a) ‘alLJb@1S(J2/-UperULB’ 

(b) ‘af+—-x %/”’ 

(c) £7‘10’0 ‘11’ 95’ 
* 


Note that the <basic symbol> ‘LJ’ denotes a space, i.e., an empty character 
position. 
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are all <string> s. The substrings ‘10’ and ‘11’ in (c) are examples of a 
«string primary), defined below. In the sense that they are surrounded by 
‘and’ they are single elements of the total <string>. Thus the <string> 
(c) can be said to have 6 elements, namely 7, ‘10’, 0, ‘11’, 9, 5. That of 
(b) can be said to consist of 2 elements. Of course a substring is itself a 
«string element> and can be further broken down. One of the purposes of 
the string handling functions suggested later in this chapter will! be to 
pick out substrings and assign them to other <string variable>s. Thus we 
now formalize the string parameter: 


«string variable) ::= identifier) (7.29) 
and so 
<string primary? ::= <string variable) | <string> (7.30) 


In a sense the <string?s are the constants of string variable)s. It is 
possible to assign a <string> to a <string variable>, but not vice-versa. 
We have now completed the analysis of particular kinds of procedure 

parameter; further examples will arise in the text. But the ramifications 
of procedures are as yet not complete, and to explain some ‘advanced’ 
features, we now move on to the various types of recursion which are per- 
mitted. 


7.3. Recursion 


We have already seen in (7.24) and the sequal, that an <actual parameter) 
which is an (expression) may contain <procedure statement)s. Clearly 
an implication is that such an <actual parameter) may contain references 
to the procedure which it is activating. That is, the procedure may be 
called while its parameters are in course of evaluation. It is appropriate 
to call this a RECURSIVE PROCEDURE CALL. 

Other types of recursion exist; in particular it is possible (7.3.3) for a 
« procedure body) to contain activations of the very procedure in course 
of execution; we shall call this type of procedure a SELF RECURSIVE 
PROCEDURE. 


7.3.1 Recursive procedure calls 
We have seen many examples of actual parameter) s in procedure calls 
which themselves contain calls on other procedures. The formal elaboration 
mechanism shows how to understand such calls. Evidently from 7.2.2.1 . 
there is nothing to prevent such a call being again the procedure just 
entered. Since the procedure is re-activated, from within itself, it is natu- 
ral to call such calls RECURSIVE CALLS, 

An example of such an application occurs in double series. 
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20 50 
Exomple 26 To sum the double series s », sin k(n + 2n) 
3 n=0 


ms 


If we write this in the equivalent form 
sO 
Se us where ui ee sin k(m+ 2n) 


then it is evident the problem reduces to two calls on a single series 
summation procedure such as that given in example 13 of section 7.2.4. 
The following <block> shows the natural form which we prove formally 
by elaborating the two successive calls. 


begin real ans; integer m, m; 


real procedure SUM(w, i, p,q); value p,q; integer p, q; 


real w; 

begin real s; s := 0.0; 
for i := p step 1 until q do s := s+ w; 
SUM :=s 

end SUM; 


ans := SUM(SUM(sin(k x (m+ 2n)), n, 0, 50) 
»m, 5, 20); 


end; 


The first elaboration gives 


begin real ans; integer m,n; 


real procedure SUM (w, i, p, q); value p,q; integer p, q; 


real w; 

begin real s; s := 0.0; 
for i := p step 1 until q do s := Si Ww; 
SUM :=s 

end SUM; 
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begin real SUM; 


begin real s; s := 0.0; 


integer p, q; 


for m:= p step 1 until q do 


SUM :=s 
end elaborated body of ‘SUM’; 
ans := SUM 


end elaborated virtual block of ‘SUM’; 
end; 


Note that the outlined areas correspond exactly. From the previous 
examples in section 7.2.4 it will already be obvious that the for-loop 
performs the partial sum over m, computing u,, by the call again of ‘SUM’. 
Elaborating this explicitly, we have the following equivalence <block >: 
begin real ans; integer m, n; 
begin real SUM; integer p,q; p := 5; q := 20; 
begin real s; s:= 0.0; 


for m := p step 1 until q do 


I begin real SUM; integer p,q; p := 0; q := 50; 1 
begin real s; s := 0.0 


for n := p step 1 until q do 


| | 
' 
! 
s := s+ sin(kx (m+2xn)); i 
SUM :=s 
lend SUM; 
1S 72 s+ SUM y 
ee a a ee 
SUM :=s 

end; 

ans := SUM 

end; 


The dotted outline again corresponds. Moreover the dotted section per- 
forms the partial sum evaluation of n, i.e., u,, for each value of m set in 
the outer for-loop. 

One of the dangers of recursive calls is their abuse through careless 
selection of the (variable)s in the inner call. 
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20 


sO 
Exomple 27. The sum y. > p* sin k(p + 2q) could be effected via 


P=5 qg=0 
either 


(a) ans := SUM(SUM(p ¢ 2x sin(kx (p+ 2x q)), q, 0, 50), p, 5, 20); 


or 


(b) ans := SUM(pf 2x SUM(sin(k x (p+ 2x q)), q, 0, 50), p, 5, 20); 


It should be clear from the above elaborations that (b) is more efficient 
than (a), since (a) will have p ¢ 2 evaluated within the p-loop as well as 
the q-loop, i.e., (a) evaluates p t 2 51 times extra. But provided this 
kind of pitfall is realized, it becomes the most natural tool with which to 
express repeated calls of the same procedure. 


7.3.2 Recursive procedures 


It is surprising 6 how long the ‘housekeeping’ operations of procedure 
entry can take, so it is to be expected that a procedure which repeatedly 
re-enters itself will be relatively inefficient. There are very few 
computations which have to be expressed in terms of a recursive definition 
and the reader is advised to avoid the construction wherever possible. A 
recursive procedure is one in which one or more <statement)s in the 


(procedure body) contain right-hand sides containing further calls dn the 
procedure being evaluated. 


qg 
Example 28 A further version of the procedure to form > term 
P 


real procedure SUM(term, p,q); value p,q; integer p, q; 
real procedure term; 
begin if q= p+ 1 then go to OUT else 

SUM := term(p) + SUM (term, p + 1, q); 


OUT: 
end SUM; 
100 
If we wished, for example, to compute ) sin(r), we could write (assum- 
r=0 


ing SUM was declared in some global (block), of course), 
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begin real answer; 
real procedure U(r); integer r; U := sin(r); 
answer := SUM(U, 0, 100); 


The formal elaboration is not possible in Algol 60, but we can easily 
understand the mechanism as follows: 


answer := SUM(U, 0, 100) causes a first re-entry, to produce 
answer := U(0)+ SUM(U, 1, 100); which in tum produces 
answer := U(0)+ U(1) + SUM(U, 2, 100) 


8 © © © © ee 


answer := U(0)+ U(1)+.... U(99) + SUM(U, 100, 100) 
answer := U(0)+ U(1)+... U(99)+ U (100) 


7.4 Code procedures 


There are many applications which are not expressible in Algol 60, but 
for which basic machine instructions exist. This is true of Fortran and 
many other high level languages. Double, or multiprecision arithmetic, 
operations on parts of words (bit manipulation) and special input-output 
are all examples of, (perhaps infrequent) needs which cannot be met 
from Algol 60. 

There is also the consideration, with any high-level language, that 
certain heavily worked parts of a program should be written in machine 
code, in order to remove some of the redundant instructions which are an 
inevitable byproduct of automatic compilation, thus causing the program 
to run faster and more efficiently. 

Consequently, any reasonably efficient Algol compiler will have 
facilities for the convenient insertion of machine, or assembly code, thus 
permitting the programmer to optimize his program, or express in Algol 
operations which cannot be expressed in the language directly, such as 
multiple-precision arithmetic, operations on packed data and parts of 
words, etc. 

An efficient compiler system for Algol will have some means of 
incorporating code in this way. Moreover, some will enable the programmer 
to more conveniently optimize his program by special functions,’® such as 
array addressing functions. However, the onus for writing heavily used 
Algol library procedures with code bodies to speed up their execution 
usually rests with the computer staff at the installation, who normally 
maintain the library systems on behalf of users. 

It is moreover a good introduction to assembly/machine code writing 
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to first try to put it into sections of tested programs and perhaps use the 
real-time clock to time the improvements, if any ! 


7.4.1 Machine/assembly codes 


Machines are so diverse in construction that their basic order (or instruc- 
ion) codes also differ widely. There is however a certain consensus of 
similarity amongst such computers as the IBM 360, ICL System 4 series 
and several others of well known make, that many readers will find little 
difficulty in relating the code used in this book to their local machine 
language. 

A recent book2* describes a theoretical computer, called MIX, which 
is a mixture of several well-known (American) computers. Since this book 
describes general assembly language programming techniques very fully, 
using the assembly language of MIX, it is an excellent reference point 
for readers wishing to know more, and in particular how Algol procedures 
may be optimized. We therefore choose to describe one such procedure in 
Algol, transform it down to canonical form, and rewrite its body in MIXAL, 
the MIX assembly code. This method is perfectly general, and the reader 
who has read ‘The Art of Computer Programming’ should have no diffi- 
culty in carrying out the same work on his own machine. 

MIX is a very typical machine, with 4000 words of main memory, each 
word being organized into 5 groups of binary digits, each comprising 6 
bits (called a byte). MIX has 6 index registers, an accumulator and 
auxiliary register, and a jump register. The general MIXAL syntax for an 
instruction is 


Coperation part) address part) <index part) <field part? 


There is insufficient space here to go into the possible replacements of 
these forms. Each can be empty) (in the Algol 60 sense) or have a 
meaning. In general the “operation part) specifies what operation is to 

be carried out on the contents of the address specified (symbolically or 
numerically or by a simple expression). If the <index part) is not <empty), 
the contents of the index register specified (an address usually) must be 
added to the address in the address part before executing the operation. 
The <field part) refers to the part of the word thereby addressed. Any 
byte, or group of bytes, within a word can be referred to in the field part. 


Example 29 LOOP STA X, 1 
This is an instruction labelled ‘LOOP’ which stores the 
contents of the accumulator in the address indirectly specified 
by X plus the address in index register number 1. 


The example chosen for this treatment is a simple sorting algorithm, 
which works on the basis of examining a list of values for the greatest, 
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comparing each element with the first. When an element is found which is 
greater, it is swopped with the first. A complete scan of the list will 
leave the greatest element at the beginning of the list. The second scan 
ignores the first element, comparing each with the second, and so on. 
Thus the scan is over a diminishing list, and takes less time. Neverthe- 
less the method is very inefficient, and is only given here since it is the 
simplest method known and illustrates our purpose well. Operations on 
array variables, as we have noted, are notoriously inefficient, and proc- 
edures of the kind are usually worth optimizing. 

Our algorithm is 


procedure SORT (a, n); value n; integer n; integer array a; 
begin integer i, j, k, z; 
comment keeping the array elements to integer values 


simplifies the working, though it is easily extended to real 
variables; 


for i := 1 step 1 until n- 1 do 
begin j :- i; 
for k := i+ 1 step 1 until n do 
if afk] > a{j] then j := k; 
z i= ali]; ali] := aljl; aljl] := z 
end 
end; 
j acts as a pointer to the current maximum in the list ay, ay,,... ap; 
The k-loop scans for the greatest with j pointing at the greatest. Follow- 
ing this the interchange is made, with z acting as a buffer (or workspace) 
for the exchange. 


If we transform out the for-loop in the above procedure, we get the 
following canonical form: 
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procedure SORT (a, n); value n; integer n; integer array a; 
begin integer i, ilim, z, k, j 
ilim := n-1; i := 1; 
Ll: if ilim-i< 0 then go to OUT; 
j:= i; ks=i4+1,; 
L2: if n-k <0 then go to OUT2; 
if a{j] - alk] <0 then j := k; 
k := k+1; goto L2; 
OUT2: z := ali]; ali] := alj] := 2; 
i:=i+ 1; goto Ll; 
OUT1: 
end; 
The problem of converting this now to assembly code depends on the 
following. We must have some convention for accessing the actual par- 
ameters, so that the assembly code can link up with the running program 
parameters. Now, conventions on parameter-passing differ so widely that 
nothing can be said definitely; so we shall assume that the parameters 
‘a’ and ‘n’ have their values passed by some means into the local assem- 
bly code variables. This connection will or, should, be described in the 
manual describing the Algol compiler for any one particular machine. It is 
likely that information will be such as to place the starting address of the 


array in some symbolic address specified by the programmer. This we 
shall represent functionally by the function call, 


p = address (a) 


where p takes the value of the starting address of the array ‘a’. Arrays 
are uSually stored ‘by rows’ (see 8.1.4) so that if our actual array as 
bounds ‘1 : n’, we shall have a, in location p, a, in location 2, ... a, in 
location i+ p- 1 and so on. The MIXAL coded version of procedure 
‘SORT’ might then look like the following: 


98 


PROCEDURES 


procedure SORT (a, n); value n; integer n; integer array a; 


code LIM=n-1 P = ADDRESS (a). 
ENT1 0 initialise i 
Ll ENT2 0,1 set j=i 
LDA P,2 load alj] 
ENT3 1,1 set k=i+1 
L2 CMPA P,3 compare a{j] with alk] 
JLE NEXT 


ENT2 0,3. set j=k 
LDA P, 2 reload a{j]} 


NEXT INC3 1 end of k loop 
CMP3 LIM 
JLE L2 
LDX  P,1_— swap ali] and afj] 
STA P, 1 
STX P,2 
INC1 1 end of i loop 
CMP1 LIM 
JL Li 


end code; 


In the context of MIX, we have here used index register 1 for i, 2 for j and 
3 fork. The current value of alj] is held in the accumulator A. 

The keen reader will undoubtedly be able to clean this up and produce 
less instructions. The object is mainly to illustrate the conversion from 
the canonical Algol resulting from the transformation of the original 

into assembly code. 
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The left-hand column is for labels (made up like Algol! identifiers), 
the second column for operators and so on. In this example the right-hand 
column is, of course, commentary put in for clarity, with the various 
groups of instructions explained. In some cases they have an obvious 
meaning, but for the complete details (and some very rewarding general 
reading), the book 22 mentioned should be consulted. 


7.5 List procedures 


This is an application making use of standard Algol 60 features in which 
a procedure can be written with a solitary procedure parameter, thus: 
procedure listV(f); procedure f; 
for i := 1 step 1 until n do £(V[i]); 


’ 


It is not obligatory in Algol 60, of course, to specify ‘f’ as a procedure, 
but to do so is helpful in understanding the workings of a procedure. Thus 
‘listV’ carries out an, as yet, unspecified function of the elements of a 
vector V, declared previously in the (program) in which the list pro- 
cedure ‘listV’ appears. 

We could now write another procedure designed to operate with ‘listV’, 
intended to set all its elements to zero — although this may not be 
obvious at first sight. 

procedure zero(y); procedure y; 
begin procedure set(x); real x; x := 0.0; 
y (set) 
end; 
If we now call these two in the statement) ; 
L : zero (listV); 


then the function, or action, is described in our usual way, by successively 
elaborating the call until a canonical form is obtained. In the first stage 
we would have 


L1 : comment first elaborate ‘zero‘; 
begin procedure set(x); real x; x :-= 0.0; 
list V (set) 
end; 


In the second stage we get 
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L2 : comment now elaborate ‘listV’; 
begin procedure set(x); real x; x := 0.0; 
for i := 1 step 1 until n do set (V[i]); 
end; 
Finally, elaborating the call on ‘set’, we obtain 
L3 : begin for i := i step 1 until n do V[i] := 0.0; end; 


The action of the (statement) labelled ‘L’ is now understood. The 
advantage of this method is perhaps that where several operations can be 
defined by means of procedures such as ‘zero’, they can be called on the 
same list without any explicit mention of the list, other than its name, 
having to appear. For example, we could go on to give a procedure to 
input a list, using the procedure ‘inreal’ of chapter 8: 

procedure listin(y); procedure y; 

begin procedure in(x); real x; inreal (1, x); 

y (in) 

end; 

The reader can verify that the call ‘listin(listV);’ will be equivalent to 
for i := 1 step 1 until n do inreal(1, V[i]); 

Similarly we could output such general lists via 

procedure listout(y); procedure y; 

begin procedure out(x); real x; outreal (2, x); 

y (out) 

end; 
In practice the writing of list procedure operations functions, such as 
‘zero’, ‘listin’ is not easy, and it is doubtful if the effort is worthwhile. 
An understanding of their operations is, however, important for the 
advanced procedures of chapter 9, where lists can be transmitted to and 


from the machine in a variety of ways. The reader is advised to write a 
few simple functions for the above list, and elaborate them. 
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In 1964, IFIP issued a report on input-output procedures for Algol 60.'' 
These procedures which we discuss in this chapter form a subset of the 
full input—output proposal of the Draft ISO Algol, '' and they are suitable 
for a rather basic system of input—output. On some small computers they 
may be all the input—oitput provided, though the idea behind their defi- 
nition was that special procedures would be derived from them by the 
designers of a particular compiler. Their bodies have to be in machine 
code, but the procedures derived from them are thought of as in pure 
Algol, although in practice this will be a heavily optimized translation 
from a canonical transformation of the original text. The 7 basic pro- 
cedures are often thus called PRIMITIVES. 


8.1 The seven primitives 


The procedure identifiers of these are additions to the list of standard 
functions (2.33) and their associated reserved identifier>s. We did not 
include them in (2.33) since they are not yet widely current, though they 
should be. Their names can be redeclared in some local <block), as 
with any <identifier>, though their defined meaning is then suspended. 

Each input-output operation is associated with some kind of peri- 
pheral device, referred to by ‘logical unit number’ or simply, ‘channels’. 
It will usually be the function of a special job control card, or job 
specification, to associate a particular peripheral with a particular 
channel number. For the purposes of this book, we have kept to the con- 
vention 


UNIT NUMBER DEVICE 
1 card reader 
2 lineprinter 
3 card punch 
4-8 magnetic tape unit 
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The channel number in any input—output procedure will refer to one of 
these peripherals, so that data may be transferred between the main store 
of any of these units via a suitable input—output procedure <statement> 
referencing the unit number appropriate. 


8.1.1 Symbol transmission 


A pair of procedures is reserved to facilitate the transfer of individual 
symbols or characters, of which the Algol 60 <basic symbol?s are a 
subset. For input there is 


procedure insymbol (channel, string, destination); value channel; 


integer channel, destination; string string, (code); 
A call on ‘insymbol’, which must take the form: 
insymbol ((arithmetic expression>, (string>, <variable>) 


will cause a symbol to be read from the input device ‘channel’. The sym- 
bol is then compared with the symbols in the ¢string? ‘string’. If the 
k-th symbol from the left of the ‘string’ is a ¢basic symbol > identical to 
that symbol input, then source = k. Otherwise if the input symbol com- 
pares with the k-th symbol (as distinct from (basic symbol>) from the 
left, then source. = - k. If the input symbol is not contained in ‘string’ 
then source = 0. 


Example 1 
INPUT SYMBOL INPUT CALL RESULT 
y insymbol (1, ‘xyz’, v) v= 2 
begin insymbol (1, ‘else begin’, k) k = 3 
$ insymbol (1, ‘$100’, m) m-=-1 
bees (1, ‘£100’, p) p= 0 


procedure outsymbol (channel, string, source); value channel, source; 


integer channel, source; string string; <code>; 


A call on ‘outsymbol’ transmits to output device ‘channel’ the (basic 
symbol> occupying position ‘source’ from the left of the (string) 
‘string’. If the symbol in position ‘source’, from the left is not a 
«basic symbol), the result is undefined. If the parameter ‘source’ is 
negative, a symbol corresponding to this value is transmitted, and the 
entire contents of ‘string’ are treated as a comment. The expected con- 
vention for negative values of ‘source’ is that they will correspond to 
control characters of a specified kind, e.g., newline, newpage, end-of- 
file, rewind. A call on ‘outsymbol’ must take the form: 
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outsymbol (<arithmetic expression), <string>, (arithmetic expression). 


Exomple 2 We give the result of the following piece of program calling 
‘outsymbol’ with different values of the third parameter. 


for k := 1, -1, -2, 6, 8, 20,5 do 
outsymbol (2, ‘BILL i> U £50’, k); 


The negative values of k will be assumed as control characters with the 
effects listed in the table below. The result would be 


k 1 -1 ~2 6 8 20 5 


error error 


result B newline newpage ae a 
Pap condition condition 


Note the use of the (basic symbol) ‘Lu’ to denote explicitly the occur- 
rence of a ‘space’ character which would not otherwise easily be dis- 
tinguishable. '£ is not a ¢basic symbol>. 

We have made some tacit assumptions about the control functions 
associated with the negative parameter in this example. The actual use 
of control and formatting procedures is strictly for chapter 9, but it should 
be observed that the ISO Draft Algol includes both the procedures of 
chapters 8 and 9. Consequently, some consistency in the interpretation of 
these is essential. 

A given control symbol will usually have an interpretation on any peri- 
pheral device used, but those without we indicate thus :- . We can thus 
give a table of conventions which we adopt in this book, although they 
will almost certainly be differently interpreted on particular systems. We 
use example 2 above, with the third parameter, k. 


CONTROL. PRINTER MAG. TAPE CARD REMARKS 
PARAMETER k_ UNIT=2 UNITS 4-8 PUNCH 
-1 newline end of record punch new format code=/ 
mark (EOR) card 
-2 newpage end of file end-of- format code=t 
mark file card 
-3 - backspace 1 - backspace (n) 
physical record 
-4 - set EOR and - rewind (n) 
rewind 


tape to start 
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The function of the format codes ‘/’ and ‘t’ are discussed in chapter 9, 
but they might well carry the interpretation above in any system; specific 
decisions are left to the implementors, as is the provision of additional 
control procedures. It is clear that all of these could theoretically be 
accommodated in the simplified system of this chapter, simply by defining 
a large enough group of control parameters of ‘outsymbol’. 

integer procedure length(string); string string; 


comment A call on ‘length’ assigns to it the number of 
<basic symbol)s in the <string> ‘string’. A call must 
take the form: 


length (< string >); 
<code>; 
Example 3. A procedure to output whole (string »s: 


procedure outstring (channel, string); value channel; 
integer channel; string string; 
comment outputs the <string> ‘string’; 
begin integer i, j; j := length (string); 
for i := 1 step 1 until j do outsymbol (channel, string, i) 
end outstring; 
Example 4 length (‘x’) is 1 
length (‘xy ‘idiot’ z’) is 4 
It will occur to the reader that even the simple procedure in example 3 
above cannot be used for string variable>s unless some means of 
assigning to ‘string’ is available. A call of this procedure would have to 
occur within the body of another procedure which had ‘string’ as a 
« formal parameter >, if ‘string’ was a <string variable>. Its only use as 
it stands is to output actual <string)s, e.g., outstring(2, ‘NEXT CASE’). 
8.1.2. Transfer of real values 
procedure inreal (channel, destination); value channel 
integer channel; real destination; 
comment A call of ‘inreal’ must take the form 
inreal (Carithmetic expression >, variable>) 
Any (number > will be correctly read from the input device indicated by 
‘channel’, and stored in the main store address corresponding to 


€ variable>. Usually at least one space (J) or any symbol other than a 
decimal point, sign, or ,, effectively will delimit the (number) which 
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is input. The expected from of the <number) will be in STANDARD 
FORMAT (chapter 9.2),7' as given by (2.9). If an <integer) is found it 
will be converted into a real equivalent; (code); 


Example 5 inreal (1, xlil) inreal (4, A) 
procedure outreal(channel, source); value channel, source; 
integer channel; real source; 
comment A call of ‘outreal’ must take the form 
outreal (<arithmetic expression), <arithmetic expression >) 


The output form of ‘source’ is in standard format, as 


+ decimal number) exponent part) 


and will usually be followed by a space (LJ) or several spaces, possibly 
as specified in some channel card, or job description. 


8.1.3 Transfer of integer values 


There is of course no reason why ‘outreal’ should not be used to output 
real AND integer quantities. Any integer quantity will be converted to 
floating decimal format, but will otherwise be correctly represented. 

Similarly, although ‘destination’ in procedure ‘inreal’ is specified as a 
real <(variable>, the (actual parameter) can be an integer <variable). 
The input <integer) is converted to real internal representation, and then 
type-transferred to integer type (compare 3.1 —(c)). No loss of accuracy 
results from this. 


Exomple6 Suppose x = 3012, then the following piece of program 
inputs its value 


begin integer x; inreal(1,x);..... 


The input can be thought of in two stages (a) x := .30120000 ,,04 (for 
an 8 digit machine), (b) x := entier(.30120000 ,,04+ .5) := 3012. The 
transfer function is automatically invoked because x is integer. 

There are no specific procedures for input—output of integer quantities, 
other than the automatic procedures ‘output n’ of chapter 9. This is 
because the bodies of any such procedures can, and are expected to be, 
expressed in terms of Algol 60 and other 7 primitives. A procedure 
‘ininteger’ for outputting integer quantities is given in the literature. 
We give here one for outputting, as an example. 


10, 11 
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Example 7 A procedure to output integer quantities. 


procedure outinteger(channel, integer); value channel, integer; 
integer channel, integer; 
begin integer d, m; d :=1; 
SCALE: d:= dx 10; 
if d> integer then d := d+ 10 else go to SCALE; 
LOOP: m := integer = d; 
outsymbol (channel, ‘0123456789’, m+ 1); 
integer := integer- mxd; d := d= 10; 
if d<1 then go to OUT else go to LOOP; 
OUT : 


end; 


8.1.4 Transfer of arrays 


It is of course quite possible to handle input—output of arrays, via the 
previous procedures. 


Example 8 To input an array, square each element, and output again. 


begin integer n,m; inreal(1,n); inreal(1, m); 
begin array A[1:n, 1:m]; integer i, j; real x; 
for i := 1 step 1 until n do 
for j := 1 step 1 until m do 
begin inreal(1, x); Ali, j] := x t 2. end; 
for i := 1 step 1 until n do 
for j := 1 step 1 until m do outreal(2, Ali, jl) 
end 


end; 


It will not escape the wary that all references here to subscripted 
«variable>s are redundant, the ‘outreal’ (statement > could well have 
been placed in the <compound statement». This is illustrative of the 
care needed in programming efficiently, particularly with arrays. 

Because the handling of arrays can be performed more efficiently than 
the explicit <for statement) will allow, the provision of some special 
procedures 10 are defined, which have code bodies. 
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procedure inarray (channel, destination); value channel; 
integer channel; array destination; 


comment Inputs from ‘channel’ the entire array ‘destination’, 
which must be an array identifier); <code>; 


procedure outarray (channel, source); value channel; 
integer channel; array source; 


comment Outputs to unit ‘channel’ the entire contents of the 
array ‘source’; <code),; 


The comments made in 8.1.2 about standard format apply in identical form 
here. In fact (number)s input or output by ‘inreal’ or ‘outreal’ should be 
in exactly the same form as for ‘inarray’ and ‘outarray’. 

The mode of storage of arrays is of importance here. In the computer, 
an array is usually stored in rows by the Algol compiler. That is, each 
row occupies contiguous locations in store, though successive rows are 
not necessarily contiguous. Thus if an instruction is given to read out a 
complete (say, two-dimensional) array from its position in the main store, 
starting at the low address end, and finishing at the high address end, 
that array will appear on the output medium serially, with each row 
following its predecessor. As an example, consider the following block): 


begin array A[1:p, 1:q] inarray (1, A); 


AGAIN : for i := 1 step 1 until p do 
for j .= 1 step 1 until q do outreal(2, Ali, j]); 


end, 


The second <statement> here ‘AGAIN’ illustrates exactly the mechanism 
of the first, ‘OUT’, to which it is identical. Namely, ‘i’ is set to 1 (first 
row), and ‘j’ runs form 1 to q (column subscripts), ‘i’ is set to 2 (second 
row), and ‘j’ runs from 1 to q (columns), and so on. 

This mechanism is perfectly general, and applies to any number of 
dimensions. One thinks of as many for-loops as there are dimensions, 
although the idea of ‘rows’ and ‘columns’ is a little difficult to envisage 


beyond two dimensions. 


Example? A (program) to input and store any two large square matrices, 
both too large to go into the main computer store, but small 
enough for 3 rows to be held at atime; to form their sum, and 
output the result. 
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begin integer n;  inreal (1, n); 
begin array rowa, rowb, rowc(1:n]; integer i, j; 
for i := 1 step 1 until n do 
begin inarray (1, rowa); outarray (4, rowa); 


comment this reads 1 matrix in, as a punch card deck from unit 
1 (Cf£.8.1 for unit numbers), row-by-row, storing each row on 
magnetic tape handler 4 


end; 

for i := 1 step 1 until n do 

begin inarray (1, rowb); outarray (5, rowb) 
comment matrix b is now on handler 5 

end; 


comment At this stage it is necessary to rewind the two tapes on 
units 4 and 5. To do this we make use of the control parameter, — 4, 
given in 8.1.1 which used with ‘outsymbol‘ will activate the rewind 
mechanisms, causing a rewind to the load point, i.e., where the 
matrices a, b are started: 


outsymbol (4, ‘rewind’, — 4); outsymbol (5, ‘rewind’, - 4); 
comment we first output a message; 
for i := 1 step 1 until 14 do outsymbol(2, ‘SUM OF a AND b’, i); 
for i := 1 step 1 until n do 
begin inarray(4, rowa); inarray (5, rowb); 
for j := 1 step 1 until n do 
rowclj] := rowa[j] + rowb[j]; 
outarray (3, rowc) 
end; 
comment the sum matrix appears as a card deck 
end 
end <program) ; 
We shall see that the more sophisticated procedures ‘output n’ of chapter 
9 permit better format control than is possible here. In particular if we 
wanted to print the matrix sum, with appropriate spacing, some kind of 


overriding format control is needed. This is provided by the procedure 
‘format (string)’ of chapter 9. 
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Full Input-Output 


In this chapter we are concemed with the input-output system proposed 
by the ACM Programming Languages Committee, '' and subsequently 
incorporated by the ISO Programming Languages Subcommittee in their 
proposed standard Algol 60. Once again it should be stressed that this is 
not yet an international standard; however the Revised Report ' left the 
options open, so to speak, on input—output, and the ISO Draft is 
undoubtedly the best input—output scheme so far to emerge. In the ab- 
sence of any competitive scheme, it must gain acceptance as a well- 
thought-out, comprehensive and flexible system, Whether it is adopted in 
the Algol system for a particular computer, is very largely in the hands of 
those who have to use the system, and it is hoped that this chapter will 
serve to explain its merits, on the basis of which they can make an 
informed assessment of the input—output system they want. In addition it 
should prove useful to those users of Control Data and Honeywell 
machines, which currently adopt this system in their Algol compilers. 


9.1 Outline 


If it is required to output on the printer (cf 8.1), 5 quantities ( (express- 
ion)s, <variable>s, etc), one simply writes 


output 5(2, ‘’, x, sin(x), x+ y, cos(thetax y), t{i]), 


This is a (procedure statement ) of a system procedure incorporated in 
the standard functions for the compiler. There have to be as many 
(procedure identifier) s as there are entries in the output parameter list, 
which means there is, theoretically, an indefinite number of such output 
procedures. In practice the scheme "limits us to 10 such procedures, and 
although they all have different names, namely ‘output n’, forOSn <9, 
the actual code is confined to one subroutine, so no extra space is used. 
The first parameter is a device, or channel number, the second parameter 
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is a (format string), the make-up of which determines the format of all 
the output parameters following. The <format string) structure is some- 
thing which will be explained in detail, but is very simple and easy to 
use — certainly more so than, say, the Fortran format statement, to which 
there are some resemblances. The actual items in the output list can be 
Carithmetic expression)s, «boolean expression)s, <variable)s. If the 
list is empty) only the <string> in the <format string) is output. 
Similarly, if the <format string» is <empty> as in our example above, the 
quantities are output in STANDARD FORMAT. 

Some extended facilities, using a procedure called ‘outlist’ are avail- 
able and are discussed also, though in practice their use seems likely to 
be unnecessary. 


9.2  Input-output procedures 
The form of the input procedure is 


procedure input n(channel, format string, el, e2, ... en); 
value channel; integer channel; string format string; 


<code> ; 


Also we have 0S n< 9. The form of the <actual parameter)s must be 
limited to <variable>s declared in the calling <program > of type real, 
integer, or boolean. It is not possible to input a <string> using this pro- 
cedure. 


The form of the output procedure is 


procedure output n(channel, format string, el, e2, .. en); 
value channel; integer channel; string format string; 
<code>; 


Here the form of the (actual parameter)s is limited to (arithmetic 
expression), <string> or “boolean expression >. 

The reader might have difficulty in understanding how this can be in 
an Algol system which, for example, insists that (formal parameter?s 
are specified. This is however a matter within the implementor’s dis- 
cretion. Algol procedures can have some or all, or none, of their <formal 
parameters specified, and it may well happen that one gets used to a 
system where all user defined procedures have to have specified par- 
ameters. It is quite consistent however that system defined procedures, 
like the input-output ones of this section, have no specifications. The 
<string> parameter ‘format string’, as we shall see, allows a very precise 
specification of the output—input parameters. Each item in the <format 
string> is separated from its neighbour by a comma, so that a 


112 


FULL INPUT-OUTPUT 


correspondence is established as between the output—input items and the 
items in the <format string). If the ¢format string) is null, items are 
transferred according to a STANDARD FORMAT. 


Example 1 If a = 815.16258, b= true, k = 156, i.e., 3 <variable)s of 
type real, boolean and integer respectively, then 


output 3(2, ‘’, a, b, k) would result in 
.81516258 ,,3 true 156 


k is printed with suppressed leading zeros and sign, and ‘a’ 
in standard floating decimal format. 


9.3. Standard format 


On input of real or integer quantities, any quantity on the input medium 
conforming to the definition (2.9) of a <number> will be transferred to the 
appropriate input <variable>. Such an input <number) will be effectively 
delimited by a <letter>, or character other than a decimal point, sign, 
(digit), or ,), because these are the possible constituents of a <number?. 
It will be usual for there to be at least one space (LJ) in front and at the 
end of the <number>. The exact specifications used in a particular 
implementation should be given in a manual which must be consulted. A 
<string> will be output as the number of symbols in the <string>, but 
«string? s cannot be input. 

On output of real quantities, the form of (2.8) which is 


<decimal number) (exponent part> 


is used. Integer quantities are printed with leading zeros suppressed. 
Usually 1 or more blank spaces is output after the <number)>, and it may 
be possible to vary this by a special channel card, or job description. 
Boolean quantities are output as given in example 1 above. 

For most applications involving small amounts of output, the null 
«format string > which gives this standard format will be adequate. If an 
item is being printed when the right-hand margin is exceeded, a new line 
is started, with the item then continued on the new line. Thus output will 
consist of numbers, strings and boolean values, printed in rows, and with 
each item sparated by at least one space and/or new line. 

In practice one will wish to control the format of output more closely 
than this, and for this reason the notion of the format string> was con- 
ceived. We now go on to discuss this, giving a formal structure along the 
the lines of the previous syntax specification for Algol 60. 
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9.4. The format string 


The <format string> is simply a list of items which are to be interpreted 
by the compiler from left to right. These < format item)s either control 
the format of the parameter in the output list to which they correspond, or 
they output specified control symbols and/or actions. 

The formal syntax follows immediately. 


(format string) ::= ‘(format secondary)’ | ‘’ (9.1) 


The null string option here we have already associated (9.3) with the 
input—output of standard format. Also 
{format secondary) ::= (format primary? | 
<format secondary), <format primary> (9.2) 
Essentially then, the <format secondary) is one or more items, separ- 


ated by commas, corresponding with the (actual parameter?)s. For 
example, 


output 5(2, ‘X1, X2, X3, X4, X5’, El, E2, E3, E4, ES) 


will output the 5 <actual parameter?s E1—E5 (cf 9.2), with El according 
to format specification X1, E2 according to X2, and so on. If the <format 
string of <format item) s is exhausted before all the (actual par- 
ameter) s are transferred (more E’s than X’s), the remaining parameters 
will transfer in standard format. Further, 


«format primary) :-= format item> | 
Creplicator) («format secondary >) | 
(<format secondary > ) (9.3) 
This second type on the RHS here denotes an abbreviation for 
«replicator> repetitions of the parenthesized quantity. The ¢ replicator) 
is usually an <integer) denoting a number of repeats. The third type on 


the RHS, with no (replicator) is used to denote an infinite number of 
repeats. 


Note also that spaces in the (format string) are ignored; consequently 
one may insert as many as necessary to make it readable. 


9.4.1 The format item 


We now give the structure of the (format primary) in its simple form of 
«format item>. 


(format item) ::= format item 1> | (alignment mark) | 


{format item) (alignment mark? (9.4) 
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The particular item affecting format of transferred parameters is 


{format item 1> ::= (number format) | <string format) | 
alpha format> | <nonformat> | 
<boolean format) | <title format> | 
<alignment mark) format item 1) (9.5) 
The syntax of these various types of (format item 1) are precise and 
detailed, and to facilitate their description, we first detine some auxili- 
ary meta-variables. 
9.4.2 Format codes, insertions and replicators 
The use of these may speak for itself, but we shall soon be giving 


examples of their use. 


(a) Format codes 

These are symbols which appear in the (format string) and have a pre- 
cise meaning, defined as follows. The later syntax will define how they 
may appear in a “format string>. 


SYMBOL FUNCTION SYMBOL FUNCTION 


A alphabetic character P boolean bit 
represented as integer 


B blank space R real untranslated 
D digit S string character 
F TRUE or FALSE T truncation 
I integer untranslated V implied decimal 
point 
L boolean untranslated J tab function 
N standard format delimiters of 
X arbitrary replicator () replicated format 
: secondaries 
Z zero suppression 
+ print the sign : format item 
separator 
-_ print the signif minus / line alignment 
(new line) 
10 exponent part t page alignment 
indicator (new page) 
es delimiters of decimal point 


inserted string 
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(b) Replicators 
In order to indicate the repeat of a given format code, we have 


{replicator ::= unsigned integer) | X (9.6) 
Exomple 2. 3B means the same as BBB 


The X denotes a dynamic replicator), the value of which is determined 
when a format procedure is called (see 9.6.1.1). Thus the <program)> can 
determine at run time how many times a given code is to be executed. 


(c) Insertions 

This facility is designed to allow the insertion of messages, or comment- 
ary in the form of an inner (string>, in the middle, if required, of number 
outputting. 


Cinsertion> ::= B| <replicator> Bj <string> (9.7) 


Using this one could insert blanks in between digits of an output 
number), or even text. This generalizes to the 


<insertion sequence» ::= empty) | <insertion sequence> 
<insertion> (9.8) 


9.4.3. Alignment marks 

One has to be a little careful here, since the output—input device speci- 

fied MAY NOT be a printer and our terminology may not be appropriate in 

the context of, say, a card punch, or magnetic tape file (see 8.1.1). 
However we need ‘control’ symbols which will throw out new lines, 

new pages, print tabulations and so forth, and these are formally 

included in 


Calignment mark) ::= /| f | J | (replicator) / | 
Creplicator> f | 
Creplicator> J (9.9) 


‘/’? means ‘go to new line’ (or, carriage return, line feed on a teletype). 
It may cause punching on a new card when the unit specified is the card- 
punch (cf.8.1.1). It may cause an end-of-record mark to be output ona 
magnetic tape unit. ‘+’ means ‘do a / and go to top of next page’. Again 
an end-of-file mark may result from this action to a card-punch or mag- 
netic tape unit. The tabulation code ‘J’ will cause the character pointer 
to skip over the tab-field and operates similarly to a typewriter. It cannot 
however be invoked on other than standard tab positions (one space) out- 
side calls of main input—output procedures ‘in list’ and ‘out list’ (see 
9.6.1.4). However it is quite possible that the tab spacing is separately 
controllable by a special control card. 
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Example 3 output 0(2, ‘2/B ‘NEXT CASE’’) would result in 2 new lines 
and then 


UNEXTUCASE 
Example 4 output 2(2, ‘//5B ‘TRIAL FUNCTION’ /’, x, f(x)) gives 
UtiuitiWwT RI ALUFUNCTION 
89675643 9-5U.17756433 9 +6 


Thus the (alignment mark>s may appear almost anywhere in the (format 
string). In this particular example, we have also used the format string) 
simply for (alignment mark)s and text; the string is null so far as 
<number format) is concerned, so that the output of the 2 <actual par- 
ameter) s will occur under the standard format settings. 


9.4.4 Title format 

In effect the whole of the previous section was about <title format). It is 
simply the name given to any combination of <alignment mark>s, 
Cinsertion sequences or messages which do not correspond with any out- 
put parameter format. 


<title format) ::= <insertion> | <title format? <insertion> (9.10) 


On input, this causes simply a skipping of the characters. If titles are to 
be input we use alpha format>. Example 3 has a <format string> which 
is wholly in title format), and similarly example 4. 


9.4.5 Non format 
It is occasionally useful to be able to output a <variable> in the intemal 
representation of the computer, and for this we have 


non format ::= I1| R|L (9.11) 


It must be used in conjunction with <variable>s of type integer, real, 
boolean respectively. If I (for example) is used with a real <variable> the 
appropriate transfer function is invoked. The details of this particular 
facility are left to the designers of the system. 


9.4.6 String format 


If an item in the output parameter list is a <string>, then it can be 
matched by a <format item) consisting of ‘S’ repeated as many times as 
there are characters in the <string> to be output. 
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(string format) ::= insertion sequence) S) | 
«string format) <S) | 
«string format> insertion) (9.12) 
Moreover 
<S> ::= S| sreplicator> S (9.13) 


Example 5 output 1(2, ‘/6B14S2B’, ‘INVERSE MATRIX’) will result in 
WUUUUU INVERSE MATRIX LI LJ 


One should observe that only the S leftmost characters will be transmitted. 
An excess of <S)s will be made up out of blanks (B). 


9.4.7 Boolean format 


Two alternative forms of boolean input—output are provided for, numerical 
(1 or 0) or symbolic (true or false). We have 


<boolean format) ::= insertion sequence) boolean part) 
<insertion sequence) (9.14) 
where the 
“boolean part? ::= P| F 


These two codes have the following effect 


input—output 


parameter Pp F 
true 1 true 
false 0 false 


Example 6 If ‘x # 0’ is true, ‘OK (r<s)’ is true and ‘bool’ is false then 


output 3(2, ‘/2BP, /2BF, 3BP’, x 4 0, OK(r< s), bool) 


will result in 


HOW tl 
1 


TRUE 0 


Example7 The listing of a card data deck looks like 


100110 
‘TRUE’ ‘FALSE’ 


To input these values and assign them to certain boolean variable) s 
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for i := 1 step 1 until 6 do input 1(1, ‘p’ bli); 
input 2(1, ‘F, F’, bool2, bool3), 
9.4.8 Number format 


By far the greater amount of work in Algol 60 is concerned with numerical 
computations, and the structure of formatting number transfer is perhaps 
understandably more complex. For example, we want to be able to trans- 
fer a <number> in any of its various allowable forms (2.9). It is worth 
referring to the syntax given in 2.2.1 and 2.2.2 in this connection, for the 
format structure parallels this. 

Before defining the formal format structures, which are rather complex, 
it is worth pointing to our aims. A (number) to be output will be 
represented in the corresponding <format secondary» by a string of 
characters which control the exact form of output. Thus 


output 1(2, ‘BBBDDDD’, n) 
where n= 1024, would give 
UUuU1 02 4 
and the same would result from 
output 1(2, ‘3B4D’, n). 
A <statement> like 
output 1(2, ‘2B8D’, n), 
with n = 1024, would give 
'1'U 00001024 
In order to suppress these leading zeros we make use of a ‘Z’ symbol 
(format code), otherwise decimal digits to be printed are represented by 


the ‘D’ symbol. This is the structure for an individual (format secondary) 
corresponding to a single output parameter. To extend this we might have 


output 3(2, ‘B8D, ‘X =’ N, ‘y =’ + DD.DDDD’, k, x, sin(x)) 
resulting in 
J 77845000 X = .5001234° ,, 6 y = - 00.4794 
The ‘N’ in the 2nd format item here is a ‘return to standard format’ code. 
The idea of representing each output ¢(number> as a sequence of 
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special characters, is often called ‘making a picture’. Of course we shall 
also want to be able to insert <alignment mark>s as well as the 
<insertion)s such as ‘X =’ and ‘y =’ above. 


The system as a whole bears some resemblance to Fortran, but is con- 
siderably clearer and more flexible and will repay careful study. 

We now come to the specific syntax for number format >, giving the 
rules by which the output appearance of a <number> is ‘pictured’ in a 
representational format string. The general form is 
<number format) ::= <sign part) decimal number format) | 

“sign part) <decimal number format? 

<exponent part format) | (9.15) 
<decimal number format) + insertion sequence) | 
<decimal number format) — <insertion sequence) 


Elaborating this, we have, 


<decimal number format)? ::= unsigned integer format? <T part> | 
Cinsertion sequence) 
<decimal fraction format> | 


<unsigned integer format? 


<decimal fraction format)? (9.16) 
Also, the 
«unsigned integer format? ::= insertion sequence) 
«integer part) (9.17) 


The various categories given are now defined. 


9.4.8.1 Sign part 
<sign part) ::= <empty> | <insertion sequence) + | 
Cinsertion sequence? -— (9.18) 


Thus if the (sign part> is null, the + sign is assumed but not printed. If 
a+ is specified, the output will be + or — as necessary. If a — is speci- 
fied, — is printed but + is suppressed if the quantity is + ve. 


9.4.8.2 Integer part 


<integer part) ::= <Z part> | <D part> | <Z part> <D part) (9.19) 


The productions on the right-hand side here are also used for <decimal 
fraction format), so we list their elaborations separately. But the zero 
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suppression facility, the €Z part) is only used for integer transfers, and 
we give this as 


(Z> ::= Z| <replicator) Z 
<Z part? ::= (Z> | «Z part) ¢Z> | <Z part) insertion> (9.20) 


A zero digit specified in the corresponding format by a ¢Z part) con- 
sisting of one or more Z’s will be suppressed on output by printing of a 
space (B code equivalent), when all the digits to its left are also zero. If 
we suppress (by accident) a non-zero digit, the <Z part) is ignored, so 
nothing is lost. 


9.4.8.3. The decimal part 
Each decimal digit to be transferred is pictured as a D. A series of them 
can either be written direct, or replicated as follows 


<D part) ::= <D> | <D part) <D> | <D part> insertion) 
where the 
«D> ::= D| <replicator> D (9.21) 
Example 8 output 1(2, ‘/8D’, 31415269) would come out as 
31415269 
Here the format has only permitted output of the exact quantity. If the 


number to be output had been too large, it is usual for a reversion to 
standard format to occur. 


Example 9 A Series of rather simple functions of two integers i, j are to 


be output. 
for i := 1, 2,3 do for j := —i step 2 until 3 do 
output 4(2, ‘2D3B, +D3B, - 2D2B, - 2ZD/’, i, j,ix j,j ti; 
This gives: 
0 1 - 1 - 01 - il 
01 + 1 01 1 
01 + 3 0 3 3 
0 2 - 2 -~ 04 4 
0 2 + 0 0 0 0 
0 2 + 2 0 4 4 
0 3 - 3 - 09 - 27 
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and so on. The dots may be helpful in indicating the character line 
positions, blanks and so on. 


Example 10 
FORMAT STRING RESULT FROM 805 RESULT FROM - 805 
-~ DDD 8 05 - 805 
- DBDD 8 05 - 8 05 
- 3ZD 805 ~ 80 5 
+ 8D +00000805 - 0000080 
+7Z + 805 - 805 
9.4.8.4 Decimal fraction format 
This is the part following the decimal point, defined as 
<decimal fraction format> ::= . <insertion sequence) <D part> 
<T part> | V <insertion sequence> 
<D part) <T part> (9.22) 


For most applications, the <T part) and <insertion sequence) will be 
<empty>. The ‘V’ is an alternative for the decimal point ‘.’ 


9.4.8.5 Truncation 
In order to have some control over input—output operations which nomally 
round off <number»s, we can arrange to transfer them by the alternative of 
of truncation, i.e., not rounding off, but simply cutting off the (number) 
according to the digit capacity of the machine. The convention for doing 
so is 

<T part) ::= ¢empty> | T <insertion sequence) (9.23) 
<«Number)s are normally rounded according to the definition 

10°“ entier(10° X + .5) = x 


This is a d-digit representation of a <number) X, and will be invoked if 
a format specification normally cuts off a quantity formatted for (decimal 
fraction format). 


A <T part) specification however will suppress this, out-putting 
instead 


1074 sign (X) entier(10% x abs(X)) 
chopping off the d+ 1- th digit rather than rounding it. 


9.4.8.6 Exponent part 
To allow the inclusion of exponents, or a modified form of standard for- 
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mat, or even an exponent format standing alone, we have 
<exponent part format) ::= ,9 <Sign part> 
(unsigned integer format> (9.24) 


The subscript ten symbol, ‘,.’ and <sign part) are deleted from the 
output if the <D part> of this is <empty>) and the exponent is zero. 


Exomple 11 Output formats 


FORMAT STRING RESULT FROM - 230.86 RESULT FROM .00023 


+ 3D.2D — 230.86 + 000.00 

+ 2Z5D.2D LILI - 00230.86 WU + 00000.00 

+ 5D,.2D — 23086 ,,- 02 + 23000,,- 08 

- D.DDDD,,)+ ZD — 2.3086,,i5+ 2 LJ 2.3000,,- 4 

- D.DDBDDB,,+ZD —- 2.30/86, t+ 2 ij 2.3000 ,»W- 4 
-3D.DT ~ 230.8 _J000.0 

—~ 4D.D ~ 0230.9 J 0000.0 

‘F =’ + 3D‘,’ F = - 230, F = +000, 

5D — 00231 00000 


9.4.9 Number input 
In general, data should be input under the same format as it was output. 
No distinction between Z and D is made in input. The main points to note 
are: 

(a) leading zeros may be input under Z format 

(b) spaces (blanks) are skipped 

(c) insertion) s are skipped 


(d) If the format specifies a sign on the left. the input sign may appear 
in any D (or Z) position as long as it is to the left of the <numben . 
A sign specified to the right, however, must be in place. 


Emmple 12 Input formats 


FORMAT STRING DATA STORED EQUIVALENT 
3D 201 + 201 
- 25 ERROR 
+ 3.6 ERROR 
+4D 295 - 25 
+ 4ZD 50635 + 50635 
450635 ERROR 
= 95 ~ 25 
+ 3ZDV2D ~ 891.586 ~ 891.59 
~ 891586 - 8915.86 
+ 5Dio+ 2D ~ 89.58682 — .89587,, + 02 
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Example 13. We give a (block) to solve the differential equation 


2 
ay = “a with initial conditions y (0) = 0. ay 
dt k dt 
library procedure “using the Runge—Kutta—Merson method. Such general 
automatic integrators will solve numerically a system of n first order 
differential equations, since any n-th order equation can be reduced to a 
set of n first order 2quations. 


= 1 via a standard 


In this particular case, if we write y, = y, ya -2 then 


, with y,(0)= 0, y,(0) = 1. 


The library procedure, which we shall not give, will have a (declaration) 
of the form 
begin 
procedure RKMERSON (x, xe, y, f, n, eps, fail); value eps, n; 
integer n; array y; real x, xe, eps; procedure f; Iabel fail; 


comment for the system of n first order ordinary differential 
equations, given as: 


dy, ; 
Liar F, (x, yy> Yao Vad G=1,2...0n 
dx 
where y,(x), yo(x), ..- y, (x) are given initial conditions, the procedure 


will integrate the system to within the prescribed relative accuracy ‘eps’, 
generating the solution vector y;|(xe), updating the starting value of the 
abscissa, ‘x’ to its required output value of ‘xe’. The procedure f(x, y, z) 
should supply to the [1:n] array z, the right-hand sides of the above 
system of equations, in order to define the problem being solved; 
<procedure body) ; 
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begin comment now for the main driver; 

real t, te, k, eps; array y [1:2]; 

procedure RHS({t, y, z); real t; array y, z; 

begin z{1] := y[2]; z{2] := y[1]=xt/k end RHS; 

input 2(1, ‘’, eps, k); 

output 1(2, ‘ ‘HEAT EQN. SOLUTION WITH K = ’/’, k); 
TRY AGAIN : eps := 10.0 x eps; 

output 1(2, ‘/‘EPS =’ .D,, + ZD’, eps); 

output 0(2, ‘/3B ‘T’ 7B ‘Y’ 13B ‘DY/DT’ /’); 

t:= 0.0; yf1] := 0.0; yf{2]:= 1.0; 

for te := .5 step .5 until 20.0 do 

begin RKMERSON (t, te, y, RHS, 2, eps, EXIT); 

output 3(2, ‘2D.2D3B,.5D,, + 2D, 3B.5D,, + 2D/’, t, y{1], y[2]) 

end; go to OUT; 

EXIT : output 1(2, ‘//5B ‘FAILED AT T =’ 2D.2D’, t); 
if eps < ,.-2 then go to TRY AGAIN; 

OUT : 
end driver 
end program; 
It is not the purpose of this book to elaborate the numerical methods of 
this example, but the ‘fail’ label is usually provided in such algorithms 
because the internal integration step length is decreased (halved) until 
the required precision is achieved, as prescribed by ‘eps‘. For steeply 
rising functions, it may happen that the step length has to be decreased 
to ‘machine zero’, that is, when ‘eps’ satisfies the machine equation: 
1+ eps = 1, eps is negligibly small, or effectively zero. Since no further 
purpose could be achieved by continuing the iterations intemal to 
‘RKMERSON’, a label ‘fail’ is provided to which control can be retumed 
in the event of such an integration failure. Since a relaxed restriction on 
the accuracy specified may succeed, our (program) tries to increase 
‘eps’ and continue the computation, at least so long as ‘eps S,,-2’. 


The output of this program might look like 
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i 2 


HEAT EQN. SOLUTION WITH K = + 6783423,, ~ 03 


EPS = .5,,-9 
T Y DY/DT 
00.50 .12345,,-26 .54321,, + 03 
01.00 .23451,,-26  .45782,,+99 
FAILED AT T = 01.23 
EPS = .5,,-8 
T Y DY/DT 
00.50 .12441,,-26  .5433,,+03 
01.00 .25567,,- 26  .4623,,+ 98 


and so on 


9.5 Page layout 


The precise interpretation of format controls depends upon a general 
specification of layout. Since most output takes place on a lineprinter 
(device 2 in this book), we shall specify this device, giving the inter- 
pretation for other devices as necessary. 


FULL INPUT-OUTPUT 


We consider the printer page as laid out in a coordinate frame, with each 
character position occupying a coordinate position. The page size is 
defined in terms of 3 parameters (L, R, P) across the page, and another 
3 down the page, (L’, R’, P’). L, R define the left and right-hand 
margins respectively, L’, R’ the top and bottom margins. Thus printing 
takes place only for character positions between L and R, and lines are 
limited per page to L’ until R’. The convention that 1< L<R and 
1< L'< R’ is observed. As we shall see, certain procedures exist to 
alter the page size during output, namely ‘hlim’, ‘vlim’, ‘hend’, ‘vend’. 
The parameters P, P’ refer to the number of characters per line and num- 
ber of lines per page, respectively. These however are physical maxima 
not usually variable by the programmer. 

Under certain circumstances automatic effects result: 


effect cause 
new line transfer output ‘/’ (line alignment code) 
Rovedion margins exceeded 
P-overflow SNe etree 


new page transfer output ‘ t ’ (page alignment code) 
R'-overflow (page overflow) 


The diagram shown illustrates a typical 136 character printer, with 
L= 1, R= 136, L’ = 1, R’ = 60. 

The descriptive procedures which alter layout can only be called with- 
in the two main procedures ‘inlist’ and ‘outlist’, though facilities will 
usually exist for changing some of them via special channel cards at the 
beginning of a run. 


9.6 Transfer of lists 


The previous sections have been concerned with a simplified form of 
input—output using the procedures ‘input n’ and ‘output n’. Undoubtedly 
for most purposes, these will suffice, but where a greater degree of 
format control is required, use is made of a specia! layout procedure 
which is called by two main input—output procedures, ‘inlist’ and ‘outlist’. 
In 7.5 we discussed the idea of a list procedure, and in this section use 
is made of this to permit the input—output of rather general kinds of 
quantity, as specified in a list procedure. 

The two procedures concerned are part of the standard system pro- 
cedures, of which the standard functions form part, and have the formal 
declaration: 


procedure in list (channel, layout, list); value channel; 


integer channel; procedure layout, list; (code); 
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and 


procedure out list (channel, layout, list); value channel; 


integer channel; procedure layout, list; (code) ; 


The procedure parameters ‘layout’ and ‘list’ here are respectively a 
(simple procedure)? which contains calls on a special format procedure, 
and a procedure which lists items to be transferred. There are some 
similarities to the Fortran format statement which takes the form 


PRINT N, list 
N FORMAT(S,, S, «+. ) 


cauSing the output of the list of variables, each corresponding to a 
format specification S,, The difference in Algol 60 is that the statement 
number N is replaced by a procedure call of ‘layout’ which contains 
calls on a format procedure, with a ‘format string) parameter as we dis- 
cussed earlier. 


Exomple 13 An advance example to show the interaction of control and 
layout procedures. 


oe 


begin procedure LAYOUT; format(‘DD.3D,,+ DB’); 
procedure listV(f); procedure f; 
for i := 1 step 1 until n do f(V[i]); 


Here, of course, i, n V are global < variable>s, but the ideas of section 
7.6 can be seen. ‘listV’ is a list procedure, with a procedure parameter, 
namely, ‘f’, which acts as a dummy operation on the list V[i]. ‘LAYOUT’ 
is a (simple procedure) which calls a format procedure ‘format’ (which 
we shortly discuss) and thus affects the subsequent output from ‘out 
list’. Clearly, although we cannot express ‘out list’ in Algol 60, it must 
contain activations of both its parameter procedures, which in turn 
activate ‘format’ and ‘f’?. The manner of operation will be clear after 
studying the examples of section 7.6 where some Algol-bodied equivalents 
of ‘out list’ were used and specific elaborations worked out. Here it is 
impossible to elaborate anything, but the same basic functions are invok- 
ed when ‘out list’ is called. 

In the Report '"'® a detailed specification of the operations of ‘in list’ 
is-given. Basically their operations are similar, and are understood in 
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terms of seven local variables, best thought of as procedures. They have 
the following functions: 


Hidden variable Function 

Hl format setting 

H2 sets horizontal margins, 
i.e., L, R 

H3 sets vertical margins, i.e., 
on R’ 

H4 line alignment, R-, P— 

HS overflow 

H6 program termination point 
(label) if data ends on 
input 

H7 tabulation setting 


These are set to standard settings, which can be over-ridden by the 
descriptive procedures (9.6.1). The standard settings are 


Hidden variable Standard setting 
H1 standard format (cf.9.3) 
H2 L = 1, R= infinity 
H3 L’ = 1, R’= infinity 
H4 dummy (not activated) 
HS 
H6 terminates program normally 


if data ends abnomally 


H7 tabulation spacing = 1 


An important observation is that these format settings can only be 
altered during a call of ‘in list’ or ‘out list’. Thus, changes resulting 
from calls of the descriptive procedures must occur in the body of the 
layout procedure. 

As a final aside, it is worth noting that the previous procedures 
‘output n’ and ‘input n’ can be written in terms of ‘in list’ and ‘out list’ 
as follows. 
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procedure output n(unit, format string, el, e2, ... en); 
value unit; integer unit; string format string; 
begin procedure A; format (format string); 

procedure B(P); procedure P; 

begin P(el); P(e2); ..... P(en) end; 

out list (unit, A, B) 


end output n; 


A virtually identical form can be written for ‘input n’. 

Although the bodies of ‘in list’ and ‘out list’ are defined in the ACM 
Report "they cannot be expressed in Algol 60. It is of some interest to 
compare the list procedures given in section 7.5, where list procedures 
were discussed in this connection. There some procedures which are 
analogous to ‘in list’, using ‘inreal’, and their actions are a clue to the 
actions of the interacting layout and list procedures of this chapter. 


9.6.1 The descriptive procedures 


These are format control procedures in general which must be called in 
the layout procedure activated in turn by ‘in list’ or ‘out list’. This is a 
necessary consequence of the format setting changes being only possible 
through access to the ‘hidden variables’ H1, ... H7. Calls on these 
descriptive procedures outside the context of ‘inlist’ and ‘out list’ will 
result in dummy (do nothing) actions, or error messages from the compiler. 

We will not list in detail the actions of the 7 procedures, complimentary 
to the ‘hidden variables’, but reference to the original paper will clarify 
their functions. 


9.6.1.1 Format procedures 
The format procedures exist in the form 
procedure format (format string); string format string; 


comment sets H1 to indicate a <format string> in the 
sense of 9.4, over-riding the standard format setting of H1 
<code>; 


In addition there are n procedures (with n unspecified, though any prac- 
tical implementation will have limits) 
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procedure format n(format string, X1, X2, ... Xn); 
value X1, X2,... Xn; integer X1, X2,... Xn; string format string; 


comment This was mentioned in section 9.4.1 (b). The effect is to 
replace each format code X occurring in the format string) by one of 
the Xi, corresponding from left to right. Also, n= 0, 1, 2... ; <code>; 


Example 14 format (—5B4D.7D,.+ 2Z) is equivalent to the execution of 
format 4(- XBXD.XD,,.+ XZ, 5, 4, 7, 2) where 5, 4,7, 2 are 
the integer replacements of the arbitrary replicators X, in 
left-right order. 


Another instance of format occurred in example 13, where it resulted in 
the vector elements V[i], to be output in the given format. 
Observe that ‘format 0’ is the same as ‘format’. 


9.6.1.2 Limits 
The procedures given by 


procedure h lim(L, R); value L, R; integer L, R; (code) ; 


and 
procedure v lim(L’, R’); value L’, R’; integer L’, R’; (code); 


will alter the ‘hidden parameter’ H2, H3. ‘h lim’ alters H2, and hence the 
horizontal limits of the left and right hand margins presumed. Similarly 
‘y lim’ alters H3 and hence the vertical limits on the top and bottom marg 
margins presumed. Otherwise these parameters have their standard 
settings (9.6). 


9.6.1.3 End of data 
The procedure given by 
procedure no data(L); label L; (code); 


alters H6 so that if a request for data is made (via ‘in list’) which cannot 
be met (run out of data), control passes to the label L. Otherwise control 
passes to an imaginary label inserted just before the final end of the 
(program). 


9.6.1.4 Tabulation 
The procedure given by 


procedure tabulation (n); value n; integer n; (code) ; 
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will set H7 to indicate a non-standard tab setting of n skipped characters, 
following a J format code in a <format string >. If the tab spacing is n the 
position of the first character in each tab field is given by 

L, L+n, L+ 2n, ... L + kn where L+ kn is the lesser of P, R (P = 
number of characters per line, R = right hand margin). It is important to 
observe that the J format code will only be effective in a (format string) 
parameter of a format procedure. The tabulation spacing is normally set 
to 1, and can only be modified during activation of ‘out list’, when the J 
code will function. Thus, calls on J in, for example, ‘output n’ will pro- 
duce a single space (B code). See, however, section 9.6.2 where a call 


‘sysparam’ can be used to control tabulation outside ‘in list’ and ‘out 

list’. 

Example 15 A square field, BMGC, of side 200 yards, has gates at 
corners M and G, and there is a bull in the field at B. A man 
enters the field at M, and runs towards the gate G with a 
uniform speed V ft/sec. The bull runs towards the man, with 


malicious intent, at 30 ft/sec. How great must V be in order 
that the man can just reach the gate unscathed ? 


C G 
M'----- - 
x SH 
; | 
Vo Ynen 


: 3 


If, in the diagram, we take B as the origin for x-y axes, as indicated, 
then B’, M’ are the positions of the bull and man at some subsequent time. 


Bh : 
<—_—____—_—_———__——600 ft——____________» 
i] ' 
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The direction of the bull’s velocity is always towards the man, thus 
B'M'is the line of relative velocity. As the man mus, so the bull’s 
direction changes, and the resulting trajectory of the bull! will be a smooth 
curve, as shown. If @ is the angle between BM’ and BM, and (x, y) are, 

for the moment, the coordinates of the bull, then the equations of motion 
are equivalent to, at time / secs, 


dx (600 ~ x) 
=— 0 6= 30. ——_ i 
x aT 30 cos 3 5 (i) 


y= a 30. sin 6 = g0.i= y) (ii) 


where S= B'M'= [(600 - x)? + (V.1-y)*]'”, y= M'M= Vo t 


It would be simple enough to write these in a form suitable for solution 
by the method of example 12. In this case we would have, if we take 
y, = Ys Yo =X; 


dy, 30(V.1t-y,) dy,  30(600 - y,) 


Ss ee ade 


dt Ss t 5 
where S=[((600-y,% + (V.t-y,?]” 


However it is of interest to program this particular computation in full 
illustrating on the way some of the ways in which the advanced input— 
output facilities are used. 

Taking equation (i), Euler’s method for an equation of the form 


dx 
— =f, y,t 
a (x, y, D 


gives 
Z1 


X, =X + J f(x,y, t)dt = x, + Rf(xo, yo, to) + R, 


zo 


where the error term 


R ~ Lig dilto, yo, to) _ 12 d’x 
Co 2 

2 dt 2 dt 
where X, = Xp) + A. 
For most purposes the truncation error is too large for this to be a 
practical method, but for problems like this, with smooth solutions, it can 
give good results. For, from (i), we see that 
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: 2 is 
R, = -30.6.sin 6 i Sa isvir Sit Gcoshe (143) 
To get this we also used the fact: tan @ =e , from (i) and (ii) from 
-x 
which we obtain @ = V cos? 6/(600 — x). If we now take A= 0.1, V= 20, 
the error R, = -3 cos? @. sin @/(600— x). This is less than h until 


x-~600, which means tolerably good results can be obtained for most of 
the integration. Thus we use an algorithm in the form of Euler’s approxi- 
mation (600 - x,) Were) 
X, =X, + re omar 1 VW =M rr 

A similar error analysis holds for (ii). 

The idea of the (program) is to input several values of V, the man’s 
speed, and compare them with the values of ya, at the point of impact, 
where the separation S is zero. 


Yn (at S = 0) 


A series of values of y,,, will be obtained, increasing towards 600 ft as 
the speed values V increase. A curve like that in Fig. 2 will be obtained. 
The answer to the problem will be an extrapolation of V when y,,,, = 600; 
however we shall not consider this stage, although the data for this might 
well be extracted from the print out of the (program) given here. 

Our program) is designed to output the positions of the protagonists 
at 5 second intervals, to output suitable messages and to terminate norm- 
ally once the last value of V has been input, followed (usually) by 
end-of-file mark. 
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begin real t, xbull, ybull, yman, Vman, dt, separation; integer ©, n, 
procedure listA(f); procedure f; 
begin f(t); f(xbull); f(ybull); f£(yman) end 
procedure listB(f); procedure f; 
begin 
output O(n, ‘/‘SPEED OF MAN =’’); £(Vman); output O(n, “(FT/SEC)‘‘) 
output O(n, ‘5B ‘DT =’’); f(dt); output O(n, ‘“(SEC)’/’) 
end; 


procedure L; 
begin format 1(‘2ZD.2DXB’, r); no data(OUT) end; 


START: n:= 1; 1n list(1, L, listB); comment setting n= 1 ensures 
that when listB is called, the calls on ‘output 0’ will be on the input 
channel, and hence will not activate: 


n:= 2; r:= 1; out list(2, L, listB); comment now, however the 
messages do go out to the printer; 


output 0(2, ‘/‘T(SEC)’ 9B ‘XBULL(FT)’ 6B ‘YBULL(FT)’ 6B 
‘YMAN(FT)’/’ ); 
yman := xbull := ybull := t := 0.0; 1 := 8; comment inserts 8 blanks; 
AGAIN: yman := yman+ Vman x dt; 
separation := sqrt((yman — ybull) f 2+ (600.0 — xbull) f 2); 
xbull .= xbull + 30.0 x dt x (600 — bull)/separation; 
ybull := ybull + 30.0 x dt x (yman — ybull)/separation; 
if t/5.0 — entier(t/5.0) = 0.0 then 
begin output 0(2, ‘/’); out list(2, L, listA) end; 
if separation = 0.0 then 
begin output 0(2, ‘/‘TAURUS RAMPANS’ /’); out list(2, L, listA); 
go to START 
end; 
if yman 2600.0 then 
begin output 0(2, ‘/‘TAURUS FRUSTRATUS’ /’); 
out list(2, L, listA); go to START 
end; 
t := t+dt; go to AGAIN; 
OUT; 


end; 
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The output of this might look like the following (dots denote blank 
Spaces) 


SPEED . OF .MAN=.+DD.DD.(FT/SEC)..... DT =..0.DD . (SEC) 
MSEC) Law's dace Ge XBULL(FT)...... YBULL(FT)...... YMAN (FT) 
SE OOo ¢ vaca +ZZD.DD........ MZZDDD i hicda ea + ZZD.DD 


SS 


TAURUS . FRUSTRATUS 


(then occurs a dump analagous to the above), and so on. 


Notice the idea of using a flexible layout procedure with the blank 
insertions depending on an X <replicator) set in the (program). This 
allows us to use the same format procedure in a variety of situations. 
Also leading zeros are suppressed. The advantage of this form of output 
is that it allows a convenient grouping of all input—output procedures at 
the beginning and their calling in the body of the <program) . The only 
alternative would be to multiply the number of direct calls on ‘output n’ 
and ‘input n’. With practice the writing of these layout and list pro- 
cedures becomes second nature, and their flexibility indispensible. 


9.6.2 A-control procedure 


Because the descriptive procedures of the previous section can only be 
activated within the scopes of ‘in list’ and ‘out list’, and consequently 
may only be called in a layout or list procedure, an additional procedure 
‘sysparam’ is provided which permits access to format variables outside, 
or in ‘open program’. This procedure is defined in the system as: 


procedure sysparam (channel, function, quantity); 
value channel, function; integer function, channel, quantity; 


comment where the format variables are defined as 0, p' the character 
and line pointers (the value of each determines the next character 
position to be output), P, P’ are the number of characters per line, 
number of lines per page (cf.9.5), respectively, and k is the standard 
number format delimiter (i.e., k blanks), then the action of ‘sysparam’ can 
be described as follows. 
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“¢ function = 1 then quantity := 9 else 
if function = 2 then p := quantity; 
if function = 3 then quantity := p’ else 
if function = 4 then p’ := quantity; 
if function = 5 then quantity := P else 
if function = 6 then P := quantity; 
if function = 7 then quantity := P’ else 
if function = 8 then P’ := quantity; 
if function = 9 then quantity := k else 


if function = 10 then k := quantity; ’ ; 


? 


Notice the method of describing part of a code body in the form of a 
Cstring> of Algol <statement)s. 


Example 16 A procedure for tabulation: 


procedure tab(n); value n;_ integer n; 
begin integer posn; 


sysparam(2, 1, posn); sysparam(2, 2, posn +n) 
end; 


A call on ‘tab’ will cause the character pointer to skip n characters, i.e., 
to jump a tabulation field. 


9.6.3 Other procedures 


The Report *' of the ISO Algol Committee includes a number of other pro- 
cedures which we have not described. A particular implementation (e.g., 
Control Nata) will carry reports in detail of their implementation. Among 
them might be mentioned ‘put’ and ‘get’, two procedures for storing items 
listed in a list procedure on backing store devices. Since they are likely 
in practice to be replaced by ‘inarray’ and ‘outarray’ in systems based on 
the ISO system, we have not discussed them here. Some systems, based 
on the ACM "! proposal solely might need to use them, and they function 
in a rather similar manner to ‘inarray’. 


9.7 Applications 


Example 17. A program) to input a set of sums of money, expressed in 
pounds, shillings and pence, and output their sum, also in 
pounds, shillings and pence. 
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begin integer L, S, D, n, i, p; 

p := 0; imput 1(1, ‘’, n); comment the number of readings; 

for i := 1 step 1 until n do 

begin input 3(1, ‘’, L, S, D); 

p:= p+ (20x L+S)x 12+D 

end of input, with pence sum in p; 

comment now convert the sum to L, S, D; 

L := p+ 240; p := p—L~x 240; 

S :=p+12; D:= p~S$+12; 

output 3(2, ‘/ ‘REQUIRED SUM = £’ SZDSB,ZD‘S’5B,ZD‘D’/’, L,S,D); 
end; 


Example 18 A program) to input a set of observations taken from an 
experiment, and compute and print out the mean (£ = x) and 
the standard deviation 


fix? - 12x)? 
n 


Also to output the normalized form transformation of the observations: 
(x — mean)/(standard deviation), followed by the minimum and maximum 
values of the normalized data. 


Normal variate calculation: 
begin integer n, i; 
input 1(1, ‘’, n); 
begin real mean, sum, sumsq, sdev, min, max, x; 
array data[1:n]; 
sum := sumsq := 0.0; 


for i := 1 step 1 until n do 


begin inreal(1, data[i]); sum := sum + data[i]; 
sumsq := sumsq + data[i] ft 2 
end; 
mean := sum/n; sdev := sqrt((sumsq — sum x mean)/n); 
min := max := (data[{1] - mean)/sdev; 


for i := 2 step 1 until ndo 


begin x := (data[i] - mean)/sdev; 
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if x > max then max := x else 
if x < min then min := x; 
output 1(2, ‘/’, x) 
end; 
output 4(2, ‘// ‘MEAN =’ .SD,,.+ ZD4B, ‘S.D =’ .5D,,+ ZD4B, 
‘MAX =’ .5D,,+ ZD4B, ‘MIN =’ .SD,,+ ZD ‘/’, mean, 
sdev, max, min) 
end 
end; 


It may occur to the reader that the first for-loop here has redundant refer- 
ences to ‘data[i]’. A more efficient coding of this would be 


for i:= 1 step 1 until n do 
begin real t; inreal(1,t); ali] := t; 

sum := sum+t; sumsq := sumsq+t ft 2 
end; 


In fact it would be still better to declare ‘t’ outside this loop altogether. 


Example 19 A procedure to print an array of N rows and M columns, 
printing as many columns across the page of 132 character 
positions as possible. Additional columns are output (after 2 
new lines) in separate blocks. The output formatting is 
expressed as a special (format string). 

procedure PRINTMX(ch, format, a, N, M); value N, M, ch; 
integer N, M, ch; string format; array a; 
begin integer n, m, i, j, tr, p; 
n := length(format); m := 132:n; p:= Nm; 
for r := 1,1+m while rSmxp+1 do 
begin output O(ch, ‘//’); 
for i := 1 step 1 until M do 
begin output O(ch, ‘//’); 
for j := 1 step 1 until 
(if r<mxp+1 then r+ m-—1 else N) do 
output 1(ch, format, a[i, j]) 
end i 
end r 


end PRINTMX; 
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Observe that n is the number of characters output for each element, m is 
the number of columns output in each block, across the page; p is then 
the number of complete, tilled, blocks. The reader will notice that the 
conditional (arithmetic expression); (if r<...) would be more 
efficiently located in the r-loop, just before the ‘output 0(ch,‘//’)’ 


statement. In this example we have emphasized the operations rather 
than efficiency. 
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Subset Algol 60 


The difficulty in implementing full Algol 60 on small computers led in 
1964 to the definition by IFIP of a Subset Algol 60.'' The principle 
restrictions are listed in the following, and their circumvention is dis- 
cussed. 


10.1. Integer divide 


The operator) ‘=’ denoting the integer result of dividing two integer 
quantities is omitted in Subset Algol 60. However its effect is ident- 
ical to 


integer procedure DIV(i, j); value i, j; integer i, j; 


begin integer r,p; p:= 0; 1 := i; 


Lirisr-j; 
if r<0 then DIV := px sign(i x j) 
else 


begin p:= p+1; gotoL end 


end; 


For example: ‘s := DIV(80, 3);’ is identical in effect to 


‘s := 80 + 3;’ 


10.2. No own variables 


No <variable> can be declared with the own prefix, meaning that its 
value is to be retained after control passes from the ¢block) in which 
that <variable> was declared. An obvious way of circumventing this is 


to declare this ¢variable> in a global block) at least one level 
outside. 


For example, the following piece of (program): 
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L: begin own real x; real y; 


Cr ey 


Kos ad ee elena $ x is local to ¢block> ‘L’ 


ee D 


‘x’ might be set on the first entry to ‘L’, and because it is declared as 
an own (variable), its value is available on re-entry to ‘L’. We could 
re-write this as 


LL: begin real x; 

Bie laveckidc ane See erare x is now global to ‘L’, but 
local to anew <block> ‘LL’. 
Provided no exit is made from 
‘LL’ in the time it is required 


Kis ceeeees to preserve ‘x’, the effect of 
deci deviate ‘x’ being of own type is 
ie Mec ge sp Ses simulated. 


Ce 


If there is any doubt about the sequence of ¢block> entries, the pro- 
grammer can always declare such variables at the beginning of the pro- 
gram. 


10.3 Identifiers 


Only 6 character (identifiers are distinguished, reducing considerably 
the scope for names. It is important to watch that names do not coincide 
over their first 6 characters consequently. 


10.4. Exponentiation 


The rules given in 2.5.1 are valid, with the exception of x f i where 
i<0. Thus if both i, j are of integer type, then 


both jis itk and jc=i tf C8) 


are illegal, for the exponent is only allowed to be an (unsigned integer >. 
The first of the examples above would have to be reprogrammed using 
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perhaps a real (variable>, as for example: 
begin real x; x :=k; j := entier(i t x); 
As an alternative one could write the explicit form: 
j := entier(exp(k x In(i)); 

Of course ‘j := i t ( 8)’ could be rewritten as ‘j := 1.0/i ft 8;’ with 
the correct rounding coming automatically. This is interpreted by the 
rules of 2.5.1. 
10.5 Designational expressions 
The definition (3.22) of <designational expression) is simplified to 

<designational expression) ::= <label> | <switch variable) 
Thus. for example, the <go to statement) 


go to if Ab<c then L17 else 
q [if w<0 then 2 else n] 


must be replaced by 


if Ab <c then go to LI17 else 
go to q [if w<0 then 2 else n] 
Again, the <block> 
begin integer v; 


SY 


begin switch S := S1, $2, Q{M], if v >-5 then S3 else S4; 


go to S[4]; 
$4: 


would need to be replaced by something like 


begin integer v; 


go to S[if j <4 then j else 
if v>—S then 4 else 5] 


Cy 
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10.6 For-loop variables 


The loop <variable> in a <for-clause> (5.2) is restricted to a non- 
subscripted form (2.16, 2.11), so that we have 
«for clause) ::= for (simple variable) := (for list) do 
For example, 
for i{k] := 1 step k until n do S; 
would need to be replaced by 


for ii := 1 step k until n do 
begin i(k] := ii; S end; 


One suspects that many uses of subscripted variables as for-loop 
variables are in any case redundant, and certainly a source of huge 
inefficiency. 


10.7. Call by name 


This is restricted too. The <actual parameter > is restricted to be only an 
(identifier) or a <string>; in particular (expression) s are not permitted. 
If, however, the parameter is called by value, an expression) may be 
used. 

If we examine example 13 of chapter 7 where a general finite series 
summation algorithm was given, and example 14, where it was applied to 
sum the series 


x G? + 1) sin 3/) 
3=0 


then the call 
answer := SUM((j f 2+ 1)x sin(3 x j), j, 0, 100) 


is clearly illegal in Subset Algol 60. We should have no alternative but 
to write a procedure defining the series, and rewrite ‘SUM’ with a pro- 
cedure parameter, as we did in example 22 of chapter 7. 


10.8 Recursion 


No recursion of any kind is permitted. One hardly ever writes recursive 
procedures, as they are usually inefficient, and may be often rewritten 
non-recursively with a little thought. But recursive calls of procedures 
are often used to express double sums, multiple integration, and so on, 
wherever a procedure is given defining a single stage process. This is 
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useful, and we shall show how the problem can be got around. In fact it 

is probably preferable to use this sort of method instead of straight 

recursive calls, even when the Subset restrictions are not present. 
Consider again the double sum 


20 #& 
> d sin(k(p + 2x q)) 


p=sqr=0 


which can be separated into the partial sums: 
20 sO 
dsum = ) fl(p), fl(p)= > f(p, q), fp, q) = sin(k(p+ 2x q)) 
pas 7=0 


begin real procedure SUM(w, p,q); value p, q; 


integer p, q; real procedure w; 


begin real s; integer i; s := 0.0; 
for i := p step 1 until q do s := s+ w(i); 
SUM :=s 

end SUM; 


comment now follows the part actually defining the problem; 


real procedure F1(i); value i; integer i; 
begin real procedure F(j); value j; integer j; 
F := sin(k x (i+ 2x j)); 
Fl := SUM(F, 0, 50) 
end FL; 
answer :: SUM(F1, 5, 20); 
For the complete list of restrictions the reader should consult the 
Standard, '’ but we have listed here the most significant ones. In addition, 
procedures must have all their parameters specified, and (actual par- 
ameters’s must be of the same type as the corresponding (formal par- 


ameter>s. Thus care should be taken in framing or using library procedures, 
particularly as parameter procedures. 
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Basic Symbols 


Algol 60 is built up of the following <basic symbol ?s. The <basic 
symbol) is itself defined as 


<basic symbol) ::= <letter> | <digit> | “boolean value) | <delimiter> 
where 
(letter) ::= A|B|C|D/E|F|G|H|I|J|K|L|M|N|O|P|Q|R|S|T| 


U|V|W|X|¥ |Zlalble|dle|flgelhlilj|k|1|m|n]o|p| 
q|ris|tluly|w|xly {2 
Also 
(digit? ::= 0{1{/2|3|4|5|6[|7|8|9 


<boolean value) ::= true | false 


<delimiter> ::= operator? | <separator) {| bracket) | 


<declarator> | <specificator> 


<operator? ::= arithmetic operator) | <relational operator) | 


«boolean operator) | <sequential operator) 
<arithmetic operator) ::= +|-|x|/| f|+ 
Crelational operator) ::= <|<[=|>|2 [#4 
<boolean operator) ::= =|D{ Vl Aq 
«sequential operator) ::= go to| if| then | else | for| do 
<separator) ::=,|.|0]:|;3]|:=|U| step | until | while | comment 


Cbracket> ::= (|) |C]1]| ‘|’ | begin | end 
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<declarator> ::= own | boolean | integer | real | array | switch | 
procedure 
(specificator> ::= value | label | string 


These (basic symbol)s are used in combinations ‘produced’ or gener- 
ated by the syntax as given in appendix 3, and amplified with semantics 
in the body of the book. There are 116 of these symbols, which are often 
not available on certain kinds of paper tape, or punched card reproducing 
equipment. The next appendix deals with the differences as provided in 
the intemational standards. 
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ISO Hardware Basic Symbols 


In view of the proliferation of punched card and paper tape codes, this 
section lists the more common ones, particularly those coming into use 
on up to date machines. These codes are based on codes agreed at the 
level of the Intemational Standards Organisation (ISO). Also,given are 
the actual characters used to represent Algol basic symbols. Usually the 
graphic printed is the same for paper tape and cards, on any given 
machine possessing both media. This gives rise to some curious and 
irritating compromises, which however are inevitable in the context of a 
machine used for languages other than Algol 60. 

There are actually 116 basic symbols in Algol 60, and no card punch 
or tape punch can produce the whole range (though the Friden Flexo- 
writers get very close on paper tape). However a great deal can be done 
by punching compound characters, such as ‘:=’ and ‘-’. A little is 
said first about card codes in general, although the reader is urged to 
consult the codes specified in the manuals for his particular choice of 
computer. 


2.1 Card codes 


Punched cards are usually of the form shown below, with 80 columns 
across, each column containing 12 punchable rows, labelled from top to 
bottom, as 12, 11, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9. Thus the character with 
holes punched in rows 11 and 8 of any column is referred to as ‘11-8’, 
and is represented graphically by the symbol ‘Q’. 

Card codes are commonly available in the following standard classes: 


(a) Hollerith Code. Sometimes also known as BCD (Binary Coded 
Decimal) or as the IBM Fortran Scientific Set or USH (US Hollerith). 
The European DIN code is practically identical. 


(b) EBCDIC Code (Extended Binary Coded Decimal Interchange Code). 
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Hollerith Card Codes 


Punch Character Punch (a) (b) (c) (d) 
12-1 A 12 + t + + 
12-2 B 11 ~ - - - 
12-3 Cc g-1 / / / / 
12-4 D NIL Space | space | space | space 
12-5 E 2-8 : & 
12-6 F 12—2-8 < 
12-7 G 11-—2-8 Vv 
12-8 H G—2-8 ] 
12-9 I 3-8 = = = = 
11-1 J 12-—3-8 : i : ; 
11-2 K 11-3-8 | $(£) £ ($) $ $ 
11-3 L g—3-8 ; P ; ; 
11-4 M 4-8 : ') ' @(:) 
11-5 N 12—4-8 ) ) ) ) 
11-6 @) 11-—4-8 * - . i 
11-7 P f-—4-8 ( ( ( ( 
11-8 Q 5-8 < : 
11-9 R 12-5-8 > ( % 
9-2 S 11-5-8 | ] 7 
g-—3 T g—5-8 > 
g—4 U 6-8 > 
G—5 V 12—6-8 | 
@-6 W 11-6-8 | ; # 
g—7 X 6-8 = 
g—8 Y 7-8 [ & 
g—9 Z 12-—7-8 ; 

11-—7-8 > 
g i) g—7—8 A g 
1 1 
2 2 
j i Machines listed here are 
5 5 (a) IBM 7090, 360 
6 6 (b) Control Data 6000, 3000 series 
7 7 (c) Univac 1107/1108 
: : (d) Honeywell 200, 3000 
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Algol/Hollerith hardware representation 


ALGOL 
SYMBOL (a) (b) (c) (d) (e) 
A-Z A-Z A-Z A-Z A-Z A-Z 
g—9 9-9 g-9 g-9 9-9 g-9 
+ + + + + + 
x * * * * 
/ / / / / / 
7 if’. / ot 'DIV' // 
t "POWER' or ** 'POWER' + bs 
< -'LESS' 'LESS' LSS *LT* 
< "NOT GREATER’ 'NOT GREATER' LEQ _ 'LE' 
= 'EQUAL' or= 'EQUAL' or= EQL 
= 'NOTLESS' "NOT LESS' GEQ_ 'GE' 
> 'GREATER' ‘GREATER’ GTR ‘GT 
# "NOTEQUAL' ‘NOT EQUAL' NEQ _ 'NE' 
= ‘EQUIV! ‘EQUIV’ EQUIV 'EQV' 
2D) 'IMPL' 'IMPL' IMPL ‘IMP’ 
V 'OR' 'OR' OR 'OR' 
A ‘AND' 'AND' AND 'AND' 
T 'NOT' 'NOT' NOT  ‘'NOT' 
10 : ! & % 
: or 
: 7 r $or; 2 
7 =or..= -= OFr..= 1s i= 
( ( ( ( ( 
) ) ) ) ) 
[ (/ (/ (/ 
] / /) /) 
7 1¢ ¢ 1 “a 
’ ty! ‘y' t @ 
Ld blank blank blank blank 


Note: The machines (a)—(d) are the same as on the previous page. 
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EBCDIC card codes 
Punch Character 
12-1 
12-2 
12-3 
12-4 
12-5 
12-6 
12-7 
12-8 
12-9 
11-1 
11-2 
11-3 
11-4 
11-5 


space | space | space 


bubdbh 
NXxXE<SCCHUYMOVOZECAUHLTOWVMIA> 


| 
0 


Notes: The machines referred to are 
(a) IBM 360 

(b) ICL System 4 (English Electric) 
(c) ICL 1900 

(d) ICL 4100 (Elliott) 


As, before the first column (alphanumerics) 
are common to all EBCDIC and Hollerith code: 


wWwmnNA nA WNHYH @ a] 
OmAAINANAMH AWN PH 


152 


APPENDIX 2 


Algol/EBCDIC hardware representation 


ALGOL 
SYMBOL (a) (b) (c) (d) 

A-Z A~-Z A~-Z A-Z A-Z 

g—9 g—9 g-9 g-9 g-9 
+ + + + + 
/ / / is / 
7 i oF ‘if "DIV" 
| "POWER' or ** saath t or '*#! t 
< < <or'LT' <or'LT' < 

< <= <= or'LE' 'LE' "LE? 
= "EQUAL' or = = or 'EQ' = or 'EQ' = 

2 >= >= or 'GE' 'GE' "GE" 
> > > or 'GT' > or 'GT' > 

# = #or '=or'NE' #or'NE! "NE" 
= ‘EQUIV! ‘EQUIV! ‘EQUIV’ "EQUIV" 
5 'IMPL' 'IMPL' 'IMPL' "IMPL" 
Vv "OR' or | ‘OR' or | 'OR' "OR" 
A & ‘AND' or & ‘AND' "AND" 
“| | “lor 'NOT' ‘"NOT' "NOT" 
10 ; '10' or @ & or '10' 10 
= i= I= = Ore I= 
( ( ( ( ( 
) ) ) ) ) 

[ (/ ‘<'or(/ [ or ‘<' [ 

] /) ">! or /) Jor '>! ] 

i ) ( 
oy B) 

u blank blank % or'—' blank 


The machines (a)—(d) are the same as on the previous page. 


2.2 Paper tape codes 


Practically all computing systems of recent manufacture use the standard 
8 track paper tape code known variously as ASCII or ISO code. Originally 
fomulated by the British Standards Institution, this code became the 
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American Standard Code for Information Interchange (ASCII), and is now 
adopted as an intemational standard, hence the name ISO-code. 

The code actually defines only 7 bits of punching per character, but an 
eighth, parity bit, is used to reduce input errors. Thus each actual punch- 
ing is made up of either an even (usually) or odd number of holes, so that 
an attempt to read a wrong parity code will cause an error to be signalled. 
The old 5 track tape codes were incapable of a parity channel, so that 
many input, or punching errors went undetected. 

The code listed below is the ISO 7 bit code which is common to the 
machines mentioned already in this appendix which have paper tape 
facilities in addition to punched cards. All of these machines use the 
EBCDIC code, and the graphical characters correspond in both represent- 
ations. Thus the Algol 60 basic symbols will not be different from those 
in section 2.1, and consequently will not be listed again. 

Only those codes are shown which represent the Algol 60 basic 
symbols. The parity track, not shown, would appear to the left of the 
punchings illustrated. 
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ALGOL ALGOL 
SYMBOL PUNCHING SYMBOL PUNCHING 

A 1000.001 G 0110.000 
B 1000.010 1 0110.001 
Cc 1000.011 2 0110.010 
D 1000. 100 3 0110.011 
E 1000. 101 4 0110.100 
F 1000.110 S 0110.101 
G 1000.111 6 0110.110 
H 1001.000 7 0110.111 
I 1001.001 8 0111.000 
K 1001.010 9 0111.001 
i 1001.011 + 0101.011 
M 1001.100 = 0101.101 
N 1001.101 / 0101.111 
O 1001.110 < 0111.100 
P 1010.000 7 0111.101 
Q 1010.001 > 0111.110 
R 1010.010 : 0111.010 
Ss 1010.011 : 0111.011 
T 1010.100 ( 0101.000 
U 1010.101 ) 0101.001 
V 1010.110 0101.110 
W 1010.111 , 0101.100 
x 1011.000 t 1011.110 
Y 1011.001 x 0101.010 
Z 1011.010 [ 1011.011 

] 1011.101 

0100. 111 


The last symbol here, the prime, is not an Algol 60 symbol, but is used 
in making up compound symbols, as indicated in the EBCDIC/ALGOL 
section. The conventions for making these symbols up are the same. As 
in 2.1 we have not included the basic word symbols which are compound 
symbols made up from primes and letters. Lower case letters are not 
permitted in the systems referred to, either in paper tape or cards. 
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Syntax Summary 


We give here a complete list of the meta-equations defining Algol 60 
syntax, or grammar. There are some minor differences in the definitions 
and metavariables used, from the Revised Report, but the language 
described is still, of course, Algol 60, and the departures made are purely 
in the interests of clarity. This concise grammar may serve conveniently 
for the programmer wishing to check his work. 


Numbers reference 
<number) ::= unsigned number) | + <unsigned number) | 
— unsigned number) (2.9) 
unsigned number) ::= decimal number> | “exponent part> | 


<decimal number) exponent part? (2.8) 


<decimal number) ::= (unsigned integer) | <decimal fraction) | 


unsigned integer) <decimal fraction) (2.7) 


<exponent part? ::= 9 Cinteger) (2.6) 
<decimal fraction) ::=. Cunsigned integer> (2.5) 
Cinteger> ::= unsigned integer? | + <unsigned integer) | 
— unsigned integer> (2.4) 
unsigned integer) ::= <digit> | (unsigned integer> digit» (2.3) 
Variables 
Cidentifier> ::= <letter> | <identifier> <letter> | 
<identifier> digit) (2.10) 
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(variable) ::= (simple variable? | <subscripted variable) (2.16) 
«simple variable) ::= <identifier> (2.11) 
<subscripted variable) ::= array identifier? (<subscript list>] (2.12) 
Carray identifier> ::= <identifier> (2.13) 

<subscript list? ::= “subscript expression? | “subscript list>, 
«subscript expression> (2.14) 
«subscript expression)? ::= ‘arithmetic expression? (2.15) 


Variable declarations 


<arithmetic type declaration) ::= “arithmetic type> 
<type list> (2.17) 
Carithmetic type> ::= real | integer | own real | own integer (2.18) 
<type list) ::= (simple variable) | 
«simple variable), <type list) (2.19) 
<arithmetic array declaration) ::= array “array list> | 


<arithmetic type) 
array array list> (2.20) 


Carray list> ::= (array segment> | 
(array list?, array segment> (2.21) 
<array segment) ::= (array identifier) { (bound pair list) ] | 
array identifier>, (array segment > (2.22) 
<bound pair list? ::= <bound pair> | 

<bound pair list>, <bound pair (2.23) 
<bound pair) ::= lower bound) : <upper bound> (2.24) 

«lower bound) ::= arithmetic expression> 
upper bound> ::= arithmetic expression? (2.25) 

Simple arithmetic expressions 

“simple arithmetic expression) ::= term) | “adding operator) <term> 


| <simple arithmetic expression > 
(adding operator) <term> (2.26) 


Cadding operator) ::= + | - (2.27) 


158 


APPENDIX 3 


<term> ::= <factor> | <term) (multiplying operator) (factor) (2.28) 
«multiplying operator) ::= «x |/| + (2.29) 
<factor) ::= primary) | (factor) f (primary? (2.30) 
(primary) ::= unsigned number> | <variable> | 
(< arithmetic expression ) | 
«type procedure call) (2.31) 
(arithmetic operator) ::= adding operator? | 
«multiplying operator > (2.32) 
Arithmetic expressions 
«arithmetic expression) ::= (simple arithmetic expression» | 


<if clause) 
<simple arithmetic expression) 


else (arithmetic expression» (2.34) 


Cif clause> ::= if (boolean expression) then (2.35) 
Program 
<program) ::= <block> | <compound statement) (3.19) 
Blocks 
<block> ::= unlabelled block)? | (label) : <block> (3.16) 
Cunlabelled block) ::= begin (declaration part) ; 
(statement part) end (3.17) 
«declaration part) ::= declaration) | <declaration> ; 
«declaration part > (3.18) 
(declaration? ::= type declaration) | (array declaration> | 
«switch declaration> | 
«procedure declaration) (3.13) 
«type declaration) ::= arithmetic type declaration) | 
<boolean type declaration? (3.14) 
<array declaration»? ::= arithmetic array declaration> | 
«boolean array declaration) (3.15) 
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Statements 
{compound statement) ::= unlabelled compound> | 
<label> : <compound statement>(3.5) 
{label> ::= identifier) | (unsigned integer (3.4) 
<unlabelled compound) ::= begin (statement part> end (3.6) 
(statement part) ::= (statement | 
«statement > ; (statement part> (3.7) 
<statement)> ::= unconditional statement > | 
<conditional statement > | <for statement? (3.8) 
Cunconditional statement) ::= basic statement > | 
compound statement > | 
<block >? (3.9) 
«basic statement >) ::= “unlabelled basic statement) | 
<label> : “basic statement) (3.10) 
<unlabelled basic statement) ::= (assignment statement > | 
<go to statement > | 
«procedure statement > | 
<empty > (3.11) 
<assignment statement) ::= arithmetic assignment statement> | 
“boolean assignment statement > 
Carithmetic assignment statement) ::= (left part list> 
Carithmetic expression > (3.1) 
(left part list> ::= (left part> | <Jeft part list> (left part? (3.2) 
Cleft part) ::= (variable> := | (procedure identifier) := 
<go to statement) ::= go to <designational expression > (3.20) 
<designational expression) ::= simple designational expression? | 
<if clause) 
«simple designational expression) 
else (designational expression (3.21) 
<simple designational expression) ::= (label) | 


€switch variable) | 
(<designational expression» ) 
(3.22) 
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{switch variable) ::= <switch identifier? 
[< subscript expression > ] (3.23) 
«switch identifier> ::= identifier) (3.24) 


Switch declarations 


{switch declaration» ::= switch (switch identifier) := 
« switch list? (3.25) 
<switch list> ::= (designational expression) | (switch list? , 
<designational expression ) (3.26) 


For statements 


<for statement) ::= <forclause) (statement> | 
<label> : (for statement> (5.1) 
<for clause) ::= for “variable> := (for list> do (5.2) 
Cfor list? ::= for list element? | <for list? , <forlist element» (5.3) 
<for list element > ::= (arithmetic expression) | 


<step-until element)? | “while element > (5.4) 


<step-until element > ::= (arithmetic expression) step 
Carithmetic expression? until 
Carithmetic expression) (5.5) 
<while element) ::= (arithmetic expression) while 
«boolean expression» (5.6) 
Relations and conditionals 
{relation) ::= (simple arithmetic expression > 
<relational operator > 
“simple arithmetic expression) (4.2) 
«relational operator) ::= <j{<{=|>j)2\4 (4.1) 
<conditional statement) ::= (if statement) | (if statement) else 


<statement> | <if clause) 
{for statement > | (label) : 


“conditional statement) (4.3) 


<if statement> ::= ¢if clause) (unconditional statement) (4.4) 
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Booleans 
<boolean value) ::= true’ false (6.1) 
«boolean type declaration) ::= <boolean type) <type list> 
<boolean type) ::= boolean | own boolean (6.2) 
<boolean array declaration) ::= boolean type) array array list)(6.3) 
<boolean expression) ::= simple boolean > | 
<conditional boolean expression) (6.11) 
<simple boolean) ::= <implication> | <simple boolean > 
= (implication) (6.9) 
<implication) ::= “boolean term) | <implication) 5 
“boolean term) (6.8) 
Cboolean term) ::= boolean factor) | 
<boolean term> V boolean factor) (6.7) 
<boolean factor) ::= boolean secondary) | 
“boolean factor) A “boolean secondary) (6.6) 
(boolean secondary) ::= (boolean primary > | 
“1<boolean primary) (6.5) 
«boolean primary) ::= (boolean value) | <variable> | 
«boolean type procedure statement > | 
<relation) | (< boolean expression>) (6.4) 
«conditional boolean expression) ::= (if clause) 
«simple boolean? else 
«boolean expression) (6.10) 
Procedures 
«procedure declaration) ::= (simple procedure> | 
(parameter procedure > (7.1) 
<procedure statement) ::= simple procedure statement) | 
<parameter procedure statement) (7.2) 
{simple procedure> ::= (simple non-type procedure> | 


(simple type procedure) (7.3) 
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<simple non-type procedure) ::= procedure 


« procedure identifier) ; 


«procedure body) (7.4) 

«procedure identifier) ::= identifier) (7.5) 

<procedure body) ::= (statement) | <code> (7.6) 
<simple type procedure) ::= (procedure type) 

€simple non-type procedure) (7.7) 

Cprocedure type) ::= real | integer| boolean (7.8) 

simple procedure statement) ::= (procedure identifier) (7.9) 


Parameter procedures 


(parameter procedure) ::= <non-type parameter procedure) | 
(type parameter procedure ) (7.10) 
<non-type parameter procedure) ::- procedure (procedure heading) 
« procedure body > (7.11) 
(type parameter procedure) ::= (procedure type) 


Cnon-type parameter procedure) (7.12) 
€ procedure heading > ::= procedure identifier) 
<formal parameter part > ; 
‘value part) (specification part) (7.13) 
¢formal parameter part) ::= («formal parameter list>)) (7.14) 
<formal parameter list? ::= (formal parameter> | 


(formal parameter list> , 


«formal parameter > (7.15) 
(formal parameter) ::= (identifier) (7.17) 
(specification part) ::= empty) | <specifier) 


identifier list); | 


(specification part) specifier) 


“identifier list); (7.18) 
(identifier list) ::= (identifier) | (identifier list), 
<identifier> (7.19) 
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<specifier) ::= string | real | integer | boolean | array | real array | 
integer array | boolean array | label | switch | 
procedure | real procedure | integer procedure | 
boolean procedure (7.20) 
<parameter procedure statement ) ::= ( procedure identifier > 
<actual parameter part> (7.21) 
<actual parameter part> ::= (actual parameter list >) (7.22) 
<actual parameter list) ::= (actual parameter > | 
<actual parameter list) , 
<actual parameter) (7.23) 
<actual parameter) ::= expression) | (array identifier) | 
«procedure identifier) | 


«switch identifier) | <string> (7.24) 
<value part> ::= Cempty> | value <identifier list) ; (7.25) 
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Algol 60 Programming 


This text gives a comprehensive coverage of the entire language 
as defined in the Revised Report. While it is suitable as an intro- 
duction for complete beginners, it also discusses the more ad- 
‘vanced applications. The approach is systematic, using the Backus 
Normal form metalanguage to give a precise grammatical descrip- 
tion. 

The major distinguishing feature of the book is that for the first 
time.a complete description of the ISO draft input-output system 
is given, This system, made up of the ACM input-output proposal 
and the IFIP input-output procedures. is in increasing. use on 
Jarge computers. The emphasis is on programming. efficiency, 
which will make this a valuable practical guide in industry and in 
Scientific and engineéring computation generally. 

A modified form of grammar is provided in-the appendices for 
easy Teference to correct grammatical constructions. Liberal use 
of. worked examples illustrating the language construction make 
this a Suitable text for all degree or postgraduate. students in- 
volved in computer programming and applications. 
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